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FOREWORD 


The  FAA  has  directed  that  the  Conflict  Indicator  Register  (CIR) 
be  replaced  by  the  Resolution  Advisory  Register  (RAR)  as  the 
avionics  mechanism  for  coordinating  resolution  advisories 
between  ATARS  sites  and  between  ATARS  and  BCAS.  Since  it  will 
be  some  time  before  the  RAR  can  be  fully  incorporated  into  the 
ATARS  algorithms,  a  number  of  modifications  have  been  made  to 
the  ATARS  logic  which  will  permit  testing  of  the  rest  of  the 
ATARS  design,  while  eliminating  the  special  CIR  message 
requirements,  now  obsolete,  upon  the  DABS  sensor.  These 
modifications  constitute  Revision  1  to  the  original  MITRE 
technical  report  on  the  ATARS  multi-site  algorithms. 

The  following  assumptions  and  requirements  apply  to  the  use  of 
Revision  1: 

(1)  The  uplink  of  resolution  advisory  messages  will  still 
be  performed  as  originally  specified  using  the  CIR 
format.  No  resolution  advisories  will  be  updated  on 
the  display  unless  all  resolution  advisory  messages 
are  correctly  received  on  that  scan.  Multiple 
resolution  advisories  will  be  processed  by  the 
avionics  in  the  order  specified  by  the  ground  system. 

(2)  No  CIR  rows  will  be  downlinked  by  the  sensor;  the  CIR 
Buffer  will  not  be  used  as  a  direct  interface  between 
DABS  and  ATARS. 

(3)  No  coordination  will  take  place  between  ATARS  and 
BCAS;  hence,  it  is  assumed  that  no  aircraft  will  be 
equipped  with  BCAS. 

(4)  All  adjacent  ATARS  sites  will  be  connected  by  ground 
lines;  coordination  of  resolution  advisories  between 
sites  will  be  performed  only  over  the  ground  lines. 

(5)  Site  ID  bits  will  be  downlinked  with  each  surveillance 
reply. 

The  primary  objective  in  Revision  1  is  to  compensate  for  the 
lack  of  the  CIR  downlink.  The  basic  technique  used  for  this 
purpose  is  to  create  a  "dummy"  CIR,  whenever  it  is  needed,  for 
each  DABS  aircraft  receiving  local  service.  In  order  to  resolve 
timing  difficulties  with  this  approach,  the  processing  of  site 
ID  bits  has  been  moved  to  the  Report  Processing  Task.  To  ensure 
the  timely  deletion  of  conflict  table  data  for  seam  pairs  for 
which  a  neighboring  site  has  been  responsible,  a  special 
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conflict  table  request  message  has  been  defined,  and  the  Backup 
Mode  Initiation  Routine  has  been  modified.  Also,  logic  has  been 
added  to  the  delayed  Master  Resolution  Task  to  ensure  proper 
assignment  of  site  responsibility  for  DABS-ATCRBS  seam  pairs. 

The  text  of  this  document  has  been  left  unchanged;  tne  Revision 
1  modifications  have  been  documented  by  changes  to  figures  and 
tables  only.  These  changes  are  described  in  more  detail  in  the 
following  paragraphs. 

The  dummy  CIR  is  created  and  placed  in  the  CIR  Buffer  on  a 
per-'aircraft  basis  by  the  Uplink  Delivery  Notice  Processing 
Routine  (Figure  5-2),  during  non-surveillance  processing, 
whenever  one  or  more  uplink  delivery  notices  are  returned  for 
resolution  advisory  messages.  Therefore,  CIR  processing  will 
only  take  place  when  the  uplink  of  resolution  advisories  to  an 
aircraft  is  being  attempted.  The  dummy  CIR  consists  of  the 
delivery  notice  for  each  uplinked  resolution  advisory  and  a  "CIR 
empty"  message.  The  updating  of  the  GEOG  variable  from  the  site 
ID  bits  is  now  performed  by  the  Report  Processing  Task  (Figure 
4-3)  instead  of  by  the  CIR  Processing  Task  (Figure  5-4).  A 
four-bit  field  has  been  added  to  the  DABS  report  format  for  the 
site  ID  bits.  (See  Table  3-3.)  The  effect  of  these  changes 
upon  task  sequencing  and  timing  is  shown  in  Figure  3-1  and  Table 
3-1. 

The  flow  chart  for  the  CIR  Processing  Task  (Figure  5-4)  has  been 
further  modified  to  issue  a  request  for  remote  CIR  data  whenever 
the  exchange  of  messages  with  the  CIR  has  been  unsuccessful 
because  of  data  link  failure.  This  procedure  is  already 
described  in  the  text  (Section  12.3),  but  was  not  explicitly 
shown  in  the  flow  chart.  With  a  non-CIR  DABS  sensor,  this 
feature  enables  the  local  site  to  request  help  in  delivering 
resolution  advisory  messages  from  a  neighboring  site.  In  this 
case,  the  remote  site's  CIR  Remote  Processing  Routine  will 
return  to  the  local  CIR  Buffer  a  dummy  CIR  containing  uplink 
delivery  notices  for  those  resolution  advisory  messages 
generated  by  the  local  site. 

The  CIR  Processing  Task  (Figure  5-4)  has  also  been  modified  so 
that  the  External  Pair  Deletion  Routine  and  the  External  Pair 
Updating  Routine  are  no  longer  called  when  the  CIR  is  empty. 
Instead,  a  special  conflict  table  request  message  is  used  to 
delete  external  pairs  for  which  another  site  is  responsible. 

Two  new  one-bit  fields  have  been  added  to  the  conflict  table 
request  message  for  this  purpose.  (See  Table  12-2.)  This 
special  message  is  sent  by  the  Pair  Record  Deletion  Routine 
(Figure  13-2)  whenever  it  deletes  a  pair  record  for  a  seam 
conflict  for  which  the  local  site  had  assumed  resolution 
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responsibility  (i.e.,  ATSID  =  own  ID).  The  Incoming  Seam  Pair 
Request  Processing  and  Reply  Task  (Figure  12-3)  at  the  receiving 
site  then  deletes  the  pair  record,  if  any,  for  the  pair. 

Changes  have  been  made  to  the  Internal  Pair  Updating  Routine 
(Figure  5-10)  relating  to  handoff  messages.  The  successful 
delivery  of  a  handoff  message  is  recorded  by  the  Internal  Pair 
Updating  Routine  in  all  cases  by  resetting  the  SEND  flag  for  the 
aircraft  and  setting  the  resolution  advisory  to  null  in  the 
conflict  table.  When  all  handoff  messages  have  been 
successfully  received,  the  pair  record  can  be  deleted. 

An  addition  has  been  made  at  the  beginning  of  the  Master 
Resolution  Task  (Figure  9-3)  for  delayed  resolution.  This 
addition  helps  to  ensure  the  proper  assignment  of  site 
responsibility  for  resolving  DABS-ATCRBS  conflicts  in  seam 
areas.  In  this  case,  a  potential  problem  arises  when  two  sites 
attempt  to  assume  responsibility  simultaneously  for  a 
DABS-ATCRBS  pair.  Each  site  sends  a  message  to  the  other,  and 
the  two  messages  in  effect  "pass"  each  other  on  the  ground 
lines.  Previously,  the  CIR  row  IDs  and  the  CIR  downlink  were 
used  to  resolve  this  problem.  Without  the  CIR  downlink,  the 
problem  recurs.  The  new  logic  added  to  delayed  master 
resolution  enables  both  sites  to  recognize  this  situation  (by 
finding  an  existing  pair  record  with  ATSID  not  equal  to  own  ID) 
and  to  apply  a  site~ID  priority  test  to  break  the  tie. 

Finally,  logic  has  been  added  to  the  Backup  Mode  Initiation 
Routine  (Figure  15-2)  to  ensure  the  proper  disposal  of  conflict 
data  for  seam  conflicts  resolved  by  a  failed  site.  This  new 
logic  permits  the  local  site  to  quickly  assume  responsibility 
for  such  a  conflict  where  possible  and  to  delete  the  pair  record 
otherwise.  When  the  local  site  is  capable  of  taking  over  (i.e., 
both  aircraft  are  in  the  local  service  area),  PWISF  and  the 
nandoff  bit  in  ATSID  are  set,  and  POSCMD  is  set  to  -1.  This 
allows  the  local  site,  if  it  detects  the  conflict,  to  take  over 
and  choose  compatible  resolution  advisories  on  the  next  scan. 

If  the  local  site  does  not  detect  the  conflict  (i.e.,  CMDFLG  is 
not  set),  then  the  pair  record  will  soon  be  deleted  by  the 
Conflict  Pair  Removal  Task. 

It  should  be  pointed  out  that,  since  the  CIR  will  always  be 
considered  empty  in  Revision  l,  certain  routines  will  never  be 
called  by  the  CIR  Processing  Task.  These  include: 

(1)  CIR  Threat  Correlation  Routine 
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(2)  External  Pair  Deletion  Routine 


(3)  External  Pair  Updating  Routine 

(4)  CIR  ATCRBS  Correlation  Routine 

(5)  Update  Sector  ID  Routine 

Note,  however,  that  the  last  two  of  these  routines  are  used  by 
other  tasks.  ATCRBS  correlation  must  be  performed  by  the 
Incoming  Seam  Pair  Request  Processing  and  Reply  Task,  while  the 
Update  Sector  ID  Routine  is  used  by  the  Conflict  Pair  Removal 
Task . 

Because  of  the  Revision  l  modifications  to  this  document, 
certain  parts  of  Section  15,  "Failure  Mode  Operation,"  are  no 
longer  accurate.  Section  15.4,  "Incomplete  CIR  Downlink 
Report,"  is  obsolete;  the  CIR  downlink  can  no  longer  fail. 
However,  it  is  still  true  that  CIR  processing  will  only  be 
performed  for  an  aircraft  if  a  successful  uplink  delivery  notice 
has  been  returned  for  each  resolution  advisory  which  was  to  be 
uplinked.  Section  15.5,  "ATARS  Selects  Incompatible  Resolution 
Advisory,"  is  also  obsolete.  With  Revision  1,  ATARS  is  assumed 
to  obtain,  via  ground  lines,  all  information  needed  to  pick 
compatible  resolution  advisories.  Since  no  CIR  is  actually 
downlinked  and  the  dummy  CIR  is  always  declared  to  be  empty,  the 
CIR  Processing  Task  will  always  find  the  resolution  advisories 
chosen  by  the  local  site  to  be  compatible  and  will  never  force 
their  recomputation.  Section  15.6,  "Failure  of  Ground 
Communications  Channel,"  is  partly  in  error.  Without  the  CIR 
downlink,  a  ground  communications  channel  between  sensors 
becomes  a  critical  element  for  ATARS  operation.  The  loss  of  a 
ground  line  could  result  in  duplicate  or  conflicting  advisories 
being  received  by  an  aircraft  in  a  seam  area. 

The  modifications  to  the  ATARS  algorithms  described  above  should 
allow  both  single  site  and  multi-site  operation  to  proceed  in  a 
normal  manner  with  a  non-CIR  DABS  sensor.  Although  no 
coordination  with  BCAS  can  take  place,  full  site-to-site 
coordination  of  resolution  advisories  can  be  achieved  via  ground 
lines. 
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INTRODUCTION 


The  purpose  of  this  document  is  to  specify  the  computer  algo¬ 
rithms  and  operation  of  the  Automatic  Traffic  Advisory  and 
Resolution  Service  (ATARS)  and  its  interface  with  the  Discrete 
Address  Beacon  System  (DABS).  Reference  1  describes  the  DABS 
sensor  which  provides  surveillance  and  communications  to  permit 
operation  of  the  ATARS  function. 

This  document  provides  algorithm  specifications  for  the 
following: 

1.  report  processing  and  tracking  logic, 

2.  conflict  detection  and  resolution  logic, 

3.  a  traffic  advisory  service, 

4.  logic  to  permit  operation  in  a  multi-site  environment, 

5.  logic  to  interface  with  the  Beacon  Collision  Avoidance 
System  (BCAS), 

6.  logic  to  treat  various  failure  conditions. 

It  does  not,  however,  specify  ATARS  procedures  to  be  followed  or 
standards  to  be  met  in  supplying  the  ATARS  function.  This 
subject  is  treated  in  Reference  1  and  the  ATARS  function  to  be 
supplied  is  subject  to  all  of  the  requirements  of  Reference  1  as 
if  this  document  were  incorporated  in  total  at  the  point  of 
reference. 

Reference  2,  which  provides  a  broad  conceptual-level  description 
of  ATARS,  is  a  useful  document  for  describing  the  philosophy  and 
goals  of  the  ATARS  function  in  detail. 

Reference  3  provides  a  detailed  description  of  the  DABS/ATARS 
function  in  the  context  of  the  Air  Traffic  Control  (ATC)  opera¬ 
tional  environment. 

Certain  conventions  and  definitions  of  terms  used  in  writing 
this  document  need  to  be  explained. 

Three  terms  are  used  in  discussing  the  facilities  at  a  par¬ 
ticular  location.  The  term  sensor  means  the  complete  DABS 
sensor  as  described  in  Reference  1.  The  term  ATARS  function 
refers  to  all  of  the  additional  hardware  and  software  required 
at  a  location  to  provide  ATARS  service.  The  ATARS  function  is 


described  by  this  document.  In  this  document  the  term,  ATARS 
function,  is  frequently  used  as  if  it  were  describing  a  separate 
piece  of  physical  equipment.  However,  the  implementation  of 
ATARS  may  not  be  done  in  physically  separable  hardware  and  so 
this  term  must  be  looked  on  as  referring  to  a  conceptually 
separate  function  or  task.  The  third  term,  site,  refers  to  the 
DABS  sensor  and  ATARS  function  at  a  single  location,  collec¬ 
tively.  Any  of  these  three  terms  may  be  qualified  by  the  terms 
local  and  remote.  Local  refers  to  an  item  at  a  single  location 
of  principal  concern.  Remote  refers  to  an  item  at  any  other 
location. 

The  term  advisory  is  used  to  refer  to  a  message  to  be  delivered 
to  an  aircraft.  There  are  several  types  of  advisory  messages 
generated  by  ATARS. 

The  term  scan  refers  to  the  act  of  the  sensor  antenna  rotating 
through  one  complete  revolution,  or  to  the  time  required  for 
this  act  to  take  place. 

Several  terms  are  used  to  describe  the  DABS  and  collision 
avoidance  avionics  equipage  of  an  aircraft  and  the  distinctions 
between  these  terms  need  to  be  understood.  An  aircraft  can  be 
classified  as  radar  only  (non-beacon)  or  as  ATCRBS  (Air  Traffic 
Control  Radar  Beacon  System)  or  DABS  depending  on  the  type  of 
beacon  transponder  carried  by  the  aircraft.  An  aircraft  can 
also  be  classified  as  either  ATARS  equipped  or  unequipped 
depending  on  whether  or  not  that  aircraft  has  an  ATARS  display. 
This  classification  is  used  to  select  appropriate  collision 
avoidance  advisories  for  a  given  pair  of  aircraft.  An  ATCRBS 
aircraft  and  radar  only  aircraft  are  always  designated  as 
unequipped.  However,  a  DABS  aircraft  may  be  either  ATARS 
equipped,  BCAS  and  ATARS  equipped,  or  neither  (unequipped). 

In  the  flow  charts,  the  invocation  of  a  separate  routine  is 
indicated  by  putting  the  name  of  the  routine  as  the  first  line 
of  a  block  which  is  set  off  by  a  horizontal  line  drawn  com¬ 
pletely  across  the  block.  The  name  is  followed  by  a  brief 
description  of  the  tasks  being  performed  by  the  routine.  With 
the  exception  of  the  routine  call  block  the  flow  chart  symbology 
conforms  to  the  standards  specified  in  Reference  4. 

State  vector  variables  which  are  subscripted  with  "next"  are 
local  variables  which  are  used  in  cases  where  both  the  updated 
and  original  values  of  the  variable  are  needed  during  inter¬ 
mediate  calculations  or  in  cases  where  it  may  not  be  clear 
whether  updated  or  original  values  are  to  be  used.  They  should 
not  be  confused  with  Che  state  vector  variable  of  the  same  name. 
In  most  cases  these  variables  are  used  to  update  the  state  vector 


field  of  the  same  name  immediately  upon  determination  of  their 
value.  Where  this  is  not  the  case  they  must  be  temporarily 
stored.  These  local  variables  are  passed  between  routines  and 
at  the  appropriate  time  are  used  to  update  the  state  vector. 

The  text  and  detailed  flow  charts  make  it  clear  when  the  local 
variables  are  used  to  update  the  state  vector. 

Section  2  is  a  brief  overview  of  the  ATARS  concept  describing 
the  services  provided  by  the  ATARS  algorithms.  This  section  is 
for  familiarization  only  and  is  not  a  complete  system 
description. 

Section  3  provides  a  high-level  view  of  the  operation  of  the 
ATARS  elements  and  discusses  the  coordination  between  them.  It 
also  describes  the  external  interfaces  of  the  ATARS  function. 

Section  A  provides  detailed  description  and  flow  charts  for  the 
report  and  tracking  tasks. 

Sections  5  through  1A  contain  detailed  descriptions  and  flow 
charts  for  the  aircraft  processing,  conflict  detection,  conflict 
resolution,  BCAS  coordination,  and  multi-site  coordination 
function  of  the  ATARS  system. 

Section  15  provides  detailed  flow  charts  and  a  description  of 
the  algorithms  to  be  implemented  under  various  failure 
conditions  of  the  DABS/ATARS  system. 

Appendix  A  collects  all  of  the  ATARS  system  parameters  and 
presents  nominal  values  for  each  of  them. 

Appendix  B  is  an  alphabetical  list  of  all  abbreviations  used  in 
the  flow  charts.  When  one  abbreviation  is  used  for  different 
words  the  intended  meaning  is  clear  from  the  context  of  the  flow 
chart . 
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SYSTEM  OVERVIEW 


The  basic  concept  of  ATARS  is  very  briefly  reviewed  here  as 
background  to  the  technical  description  of  the  algorithms.  A 
complete  functional  description  is  presented  in  Reference  2. 

The  discussion  here  is  only  intended  to  introduce  ATARS  to  the 
program  designer. 

2.1  Summary  Concept  Description 

The  Automatic  Traffic  Advisory  and  Resolution  Service  is  a 
ground  based  collision  avoidance  system  to  be  implemented  in  the 
following  environment: 

1.  full  X,  Yf  and  Z  (altitude  reporting)  surveillance  or 
non-Mode  C  (Mode  A  or  primary  data)  on  all  aircraft  in  the 
ATARS  surveillance  area, 

2.  direct  digital  data  link  to  displays  in  the  cockpits  of 
aircraft  receiving  ATARS  service, 

3.  aircraft  with  a  Beacon  Collision  Avoidance  System 
(BCAS)  operational  (see  Reference  5), 

A.  netted  and  non-netted  adjacent  DABS  sites, 

5.  an  automated  decision  process. 

The  Discrete  Address  Beacon  System  (DABS)  provides  the  fully 
automatic  surveillance  and  data-link  communications  capabilities 
which  are  prerequisite  to  the  realization  of  ATARS. 

The  ATARS  system  monitors  the  location,  altitude,  and  velocity 
of  all  aircraft  throughout  a  contiguous  airspace  via  the  surveil¬ 
lance  capability.  A  ground  based  computer  processes  the  data  and 
continuously  provides  proximity  warning  information  and,  when 
necessary,  resolution  advisories  to  aircraft  receiving  ATARS 
service.  A  limited  traffic  advisory  service  is  provided  to 
inform  ATARS  equipped  aircraft  of  nearby  non-Mode  C  aircraft. 
Certain  messages  are  generated  by  ATARS  and  displayed  to  the 
responsible  air  traffic  controller  at  the  ATC  facility  when  a 
conflict  involving  a  controlled  aircraft  is  detected  by  the 
ATARS  system. 

2.2  Types  of  Encounters 

The  ATARS  system  behaves  differently  depending  on  whether  the 
aircraft  in  conflict  are  under  control  of  the  ATC  system 


(controlled  aircraft)  or  not  (uncontrolled  aircraft),  and  on 
whether  or  not  one  aircraft  is  unequipped  to  receive  ATARS 
resolution  advisories  or  ha';  not  adequately  responded  to  the 
original  resolution  advisory.  The  types  of  messages  to  be  sent 
to  the  aircraft  and  the  parameters  used  in  the  detection 
algorithms  vary  with  the  type  of  encounter  involved. 

2.2.1  Uncontrolled/Uncontrolled 


ATARS  is  a  limited  form  of  ground-based  air  traffic  control 
which  provides  proximity  warning  and  separation  services  to 
uncontrolled  aircraft  in  a  given  region  of  airspace.  It  is 
intermittent  in  that  it  intervenes  into  the  VFR  (Visual  Flight 
Rule)  flight  regime  only  when  that  flight's  present  course  and 
altitude  put  it  in  conflict  with  other  traffic.  It  does  not 
require  the  pilot  to  file  a  flight  plan  or  to  operate  under  an 
ATC  clearance. 

The  lookahead  times  and  minimum  miss  distance  criteria  used  for 
uncontrolled/uncontrolled  conflicts  are  of  a  "tactical"  nature 
(e.g. ,  30  seconds  and  0.5  nmi)  and  imply  intervention  only  when 
a  conflict  is  imminent.  The  uncontrolled  aircraft  still  operates 
in  a  primarily  "free  flight"  mode. 

2.2.2  Uncontrolled/Controlled 


In  an  uncontrolled/controlled  encounter,  the  air  traffic  con¬ 
troller  becomes  another  element  in  the  resolution  of  a  conflict. 
The  sequence  of  events  is  as  follows.  At  a  tau  value  (relative 
range/relative  range  rate)  on  the  order  of  40  seconds  to  a 
violation  of  1.2  nmi.  horizontal  separation  or  375  feet  vertical 
separation,  a  Controller  Alert  Message  is  generated  and  displayed 
to  the  controller  with  responsibility  for  the  controlled  air¬ 
craft.  This  message  will  contain  the  conflict  resolution 
advisory  which  ATARS  would  deliver  to  the  uncontrolled  aircraft. 
At  the  same  time  a  threat  advisory  is  issued  to  both  pilots 
indicating  that  a  conflict  is  imminent  and  that  they  should 
initiate  evasive  action  as  required.  (If  the  conflict  alert 
messages  which  are  generated  within  the  en  route  or  terminal 
automation  systems  are  already  displayed  for  this  aircraft  pair, 
the  controller  message  generated  by  ATARS  will  not  be  displayed 
in  duplicate.)  The  controller  observes  the  warning  on  his 
display  and  may  elect  to  maneuver  the  controlled  aircraft  to 
avoid  the  uncontrolled  aircraft  or  simply  issue  an  advisory  on 
the  traffic.  If  no  action  is  taken,  at  about  15  seconds  later  a 
resolution  advisory  is  issued  to  the  uncontrolled  pilot  informing 
him  that  he  should  perform  the  evasive  maneuver  indicated.  If 
it  is  determined  that  the  conflict  situation  has  continued  to 


deteriorate  (tau  reaches  approximately  25  seconds)  then  the 
controlled  aircraft  is  issued  a  resolution  advisory. 

2.2.3  Controlled/Controlled  Encounters 


ATARS  will  serve  a  role  as  a  back-up  blunder  detection  system 
for  conflicts  between  two  controlled  aircraft  in  the  same  sense 
as  the  present  conflict  alert  functions  in  the  terminal  and  en 
route  automation  systems.  However,  it  is  not  intended  to 
supplant  the  ATC  system  or  routinely  issue  resolution  advisories 
to  controlled  aircraft. 

The  continued  execution  of  ATARS  with  direct  data  link  commands 
to  controlled  aircraft  as  well  as  uncontrolled  aircraft  can  be  a 
significant  transient  backup  during  catastrophic  ATC  facility 
failure.  The  controlled  pilot  routinely  receives  an  ATC  system 
failure  clearance  which  he  is  expected  to  follow  in  the  event  of 
system  failure,  with  the  ATARS  system  providing  an  additional 
emergency  collision  avoidance  function. 

A  Controller  Alert  Message  is  generated  by  ATARS  at  a  suitable 
warning  time  and,  if  not  overriden  by  a  Conflict  Alert  Message 
generated  within  the  ATC  facility,  is  displayed  to  the  respons¬ 
ible  controller.  This  message  contains  the  conflict  resolution 
advisories  for  both  aircraft  which  ATARS  would  issue.  Both 
pilots  are  informed  that  a  threat  is  imminent.  If  no  action  is 
taken  to  resolve  the  conflict,  ATARS  will  issue  resolution 
advisories  to  the  pilots  about  20  seconds  later. 

2.2.4  Encounters  With  More  Than  Two  Aircraft 


Logic  has  been  developed  to  resolve  conflicts  involving  more 
than  two  aircraft.  Details  of  this  logic  are  presented  in  a 
later  section. 

2.2.5  Encounters  With  One  Aircraft  Unequipped 

The  ATARS  system  can  detect  conflicts  between  one  equipped 
aircraft  and  one  aircraft  which  is  unequipped.  The  system 
uses  longer  lookahead  times  so  that  the  conflict  can  be  satis¬ 
factorily  resolved  by  issuing  resolution  advisories  only  to  the 
equipped  aircraft, 

2.2.6  Encounters  Which  Are  Not  Resolved  With  Initial  Resolution 
Advisory 

Special  logic  to  alter  the  resolution  advisories  is  implemented 
in  encounters  which  continue  to  deteriorate  after  initial 
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advisories  have  been  issued.  When  these  are  detected  an 
additional  advisory  may  be  issued  to  one  or  both  aircraft. 

2.3  Uplink  Message  to  be  Sent  to  Aircraft 

Behavior  of  the  ATARS  system  revolves  around  the  cockpit  display 
which  determines  the  form  of  possible  ATARS  messages.  The  ATARS 
uplink  messages  have  been  specified  to  allow  a  wide  variety  of 
display  implementation. 

2.3.1  Proximity  Advisory 

A  Proximity  Advisory  Message  is  used  to  inform  a  pilot  of  the 
presence  of  nearby  proximate  aircraft.  The  message  contains 
sufficient  information  to  indicate  the  bearing,  relative 
altitude,  and  heading  of  the  other  aircraft.  The  horizontal 
ranges  and  altitude  zones  that  determine  when  a  proximity 
advisory  will  be  issued  vary  with  the  performance  of  the  air¬ 
craft  involved.  If  one  aircraft  receives  an  advisory  because  of 
the  proximity  of  a  second  aircraft,  that  second  aircraft  (if 
ATARS  equipped)  will  also  be  issued  an  appropriate  advisory 
indicating  the  presence  of  the  first  aircraft.  Note  that  for 
all  ATARS  service,  at  least  one  aircraft  must  be  data  link 
equipped. 

2.3.2  Threat  Advisory 

When  an  aircraft  is  in  an  encounter  for  which  tau  is  less  than 
some  threshold  but  is  not  yet  so  low  as  to  require  a  resolution 
advisory,  a  Threat  Advisory  Message  is  issued  to  warn  the  pilot 
of  the  potential  collision  situation.  This  message  is  given 
approximately  15  seconds  or  more  in  advance  of  the  resolution 
advisory  to  give  the  pilots  involved  time  to  resolve  the  conflict 
on  their  own  by  locating  each  other  visually  using  the  relative 
bearing,  altitude,  and  heading  data  from  the  Threat  Advisory 
Message. 

2.3.3  Negative  Resolution  Advisory 

The  pilot  will  be  given  a  negative  resolution  advisory  when  his 
aircraft's  rate  of  closure  with  another  neighboring  aircraft  is 
sufficiently  high  but  the  issuance  of  negative  advisories  will 
provide  sufficient  separation  to  resolve  the  conflict.  These 
advisories  are  in  the  form  of  generic  "don't"  messages  ("don't 
turn  left",  "don't  climb",  etc.).  Sufficient  information  is 
provided  in  the  uplink  message  to  provide  the  pilot  with  bearing, 
altitude,  heading,  etc.  of  the  threat. 
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One  type  of  negative  resolution  advisory  indicates  that  a 
maneuver  in  a  particular  direction  could  be  hazardous,  but  that 
the  present  heading  and  altitude  are  satisfactory.  The  Vertical 
Speed  Limit  (VSL)  is  another  type  of  negative  advisory  which 
would  require  that  the  pilot  limit  his  rate  of  climb  or  descent 
to  avoid  a  nearby  aircraft. 

2.3.4  Positive  Resolution  Advisory 

A  positive  resolution  advisory  will  be  issued  whenever  it  is 
determined,  based  upon  a  constant  velocity  projection  of  the 
aircraft,  that  the  aircraft  will  come  within  some  minimum  hori¬ 
zontal  miss  distance  at  any  time  from  the  present  up  to  and 
including  some  look-ahead  time  and  whenever  a  negative  advisory 
will  not  provide  adequate  separation.  In  conjunction  with  the 
issuance  of  a  positive  advisory,  additional  information  is  avail¬ 
able  to  present  the  position,  velocity,  altitude,  and  other 
information  on  the  threatening  aircraft. 

Resolution  is  accomplished  by  selecting  the  best  maneuver  for 
each  aircraft  for  the  particular  geometry  such  that  clearance  of 
the  hazardous  approach  will  be  provided.  This  is  accomplished 
by  modeling  each  aircraft  in  all  possible  maneuvers  and  selecting 
the  one  which  provides  the  greatest  degree  of  safety  based  on 
the  consideration  of  many  factors.  The  advisories  are  removed 
when  the  aircraft  no  longer  satisfy  the  detection  criteria  for 
such  advisories. 

2.3.5  Own  Message 

The  ATARS  ground  based  system  will  when  required  provide  an  Own 
Message  to  equipped  aircraft.  This  message  will  contain  relevant 
information  to  own  aircraft  such  as  tracked  heading,  ground 
speed,  altitude,  and  turn  rate.  This  information  is  used  by  the 
aircraft's  on  board  display  processor  to  aid  in  the  presentation 
of  ATARS  generated  advisories. 

2.3.6  Terrain,  Airspace,  and  Obstacle  Avoidance  Messages 

ATARS  will  provide  an  alert  to  pilots  when  a  violation  of 
restricted  airspace  is  imninent.  Uncontrolled  aircraft  will  be 
alerted  upon  entry  into  the  Terminal  Control  Area  (TCA).  An 
alert  will  be  given  if  an  aircraft  is  too  near  the  terrain  or  an 
obstacle.  A  map  of  the  terrain  in  the  ATARS  service  area  will 
be  generated  from  U.  S.  Geological  Survey  Data  and  provided  for 
access  by  the  ATARS  processor.  Obstacles  and  restricted  air¬ 
space  regions  will  also  be  stored  for  access  by  ATARS. 


2.4  Multi-site  Considerations 


ATARS  is  to  be  implemented  in  a  complete  system  by  performing 
the  ATARS  function  in  the  same  digital  computer  facility  that  is 
resident  at  each  DABS  sensor  site.  Hence,  ATARS  is  implemented 
as  a  distributed  function  and  must  be  provided  with  a  means  for 
coordination  between  adjacent  ATARS  functions. 

The  necessary  coordination  between  ATARS  functions  can  be 
achieved  by  providing  direct  ground  communications  links  between 
adjacent  DABS  sites  or  by  using  the  information  stored  in  the 
Conflict  Indicator  Register  (CIR).  This  register  is  on  board 
each  aircraft  which  is  equipped  to  receive  ATARS  service.  Each 
ATARS  function  performs  ATARS  calculations  for  all  aircraft 
within  a  specified  geographical  area  which  represents  the  area 
of  responsibility  of  that  ATARS.  These  areas  of  responsibility 
overlap  in  the  vicinity  of  their  boundaries  to  form  seam  areas 
in  which  two  or  three  ATARS  functions  may  have  responsibility. 
The  generation  of  incompatible  resolution  advisories  to  a  pair 
of  aircraft  by  two  different  ATARS  functions  is  prevented  by 
assigning  a  priority  ordering  to  sites  which  provide  service  in 
the  seam  between  sites.  The  site  which  sees  both  the  aircraft 
and  has  the  highest  priority  is  allowed  to  resolve  the  conflict. 

2.5  ATARS  -  BCAS  Coordination 


The  coordination  of  ATARS  and  BCAS  is  through  the  CIR.  The  CIR 
is  a  resolution  advisory  storage  device  on  board  each  BCAS  and 
ATARS  equipped  aircraft.  This  device  is  read  by  BCAS  and  DABS 
sensor  interrogations.  The  current  resolution  advisories 
generated  by  either  BCAS  or  ATARS  are  taken  as  constraints  when 
either  system  selects  maneuvers  for  a  new  conflict. 


2-6 


3.  HIGH  LEVEL  PROCESSING 


This  section  discusses  the  execution  control,  the  sequencing  of 
tasks,  and  the  external  interface  of  ATARS  sector  processing. 

The  contents  and  general  purpose  of  the  Aircraft  State  Vector 
are  explained,  and  the  differences  between  the  en  route  area 
operation  and  terminal  area  operation  are  discussed. 

3.1  Execution  and  Timing 

Special  consideration  must  be  given  to  the  proper  interplay  and 
overall  control  of  the  sector  oriented  task  sequencing  of  ATARS. 
Executive  control  must  arrange  for  smooth  transitions  of  control 
and  effective  utilization  of  computer  time  resources.  Although 
a  precise  implementation  of  an  executive  program  is  not  specifi¬ 
cally  addressed,  a  solution  is  outlined  in  the  diagram  of  Figure 
3-1. 


Sector  processing  in  ATARS  provides  a  method  to  take  small, 
defined  areas  (sectors)  of  the  ATARS  surveillance  area  and 
process  the  data  from  each  sector  as  a  group.  The  ATARS  sectors 
illustrated  in  Figure  3-1  contain  two  antenna  sectors  of  11  1/4 
degrees  each.  Because  of  a  generalized  design  approach  for 
sector  processing,  the  requirement  for  an  ATARS  sector  to  contain 
two  antenna  sectors  is  flexible  and  may  be  site  adaptable.  Care 
must  be  taken  when  enlarging  the  ATARS  sectors  in  that  a  larger 
area  would  contain  a  larger  data  base  and  each  sector  would  have 
to  be  processed  in  a  shorter  time.  Also,  certain  sector  and 
time  dependent  parameters  need  to  be  adjusted. 

The  repor t-to-track  correlations  provided  by  the  DABS  sensor  are 
accepted  by  ATARS  as  they  are  received  because  ATARS  is  an 
uncorrelating  user.  Track  data  which  is  tranferred  from  DABS  to 
ATARS  is  slaved  to  the  antenna  rotation.  Target  reports  arrive 
in  the  buffer  area  in  a  batch  (one  sector's  worth  of  reports) 
once  per  11  1/4  degree  antenna  sector.  The  DABS  sensor  triggers 
the  ATARS  executive  to  read  the  report  buffer  which  includes  a 
header  containing  the  sector  identification  and  sector  time. 

The  real-time  processing  rate  of  ATARS  is  maintained  in  synchro¬ 
nization  with  the  DABS  sensor  beam.  This  antenna  sector  synchro¬ 
nization  is  important  because  the  executive  program  must  order 
tasks  to  be  initiated  and  terminated  for  the  ATARS  sector's  data 
at  discrete  times  in  the  processing  scan.  These  times,  noted  as 
critical  times  in  Figure  3-1,  refer  to  the  start  of  a  particular 
sector  in  the  processing  scan.  (e.g.,  The  first  critical  point 
noted  is  3.  This  means  no  data  for  sector  1  is  available  for 
the  Report  Processing  Task  before  the  start  of  sector  3.)  The 
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sector  numbers  in  the  diagram  illustrate  the  sequencing  of  tasks 
for  the  track  data  in  sector  1,  but  are  easily  related  to  any 
sector  by  just  adding  the  desired  sector's  identification  number 
minus  1  to  the  critical  point,  (e.g.,  Critical  point  3  on  the 
diagram  is  the  start  of  sector  3  when  referencing  the  processing 
of  sector  1  data.  If  sector  4  data  is  the  reference,  then 
critical  point  3  on  the  diagram  becomes  3  +  (4-1),  or  sector  6.) 

The  sector  processing  diagram  illustrates  all  the  tasks  that 
must  be  executed  within  one  scan  for  each  sector  of  data.  The 
task  sequencing  and  data  flow  are  shown  by  the  solid  connecting 
lines.  Each  step  in  the  process  is  dependent  on  one  or  more 
tasks  being  completed  or  an  input  buffer  being  filled.  When  two 
or  more  tasks  must  be  completed  for  a  new  task  to  start,  a 
critical  point  in  sector  processing  is  noted.  A  summary  of  the 
time  span  required  or  allowed  for  each  task  in  a  single  scan  is 
outlined  in  Table  3-1.  The  executive  program  controls  the 
initiation  and  termination  of  each  task  according  to  the  window 
length  for  each  task.  With  the  starting  times  and  processing 
windows  allowed  for  the  various  tasks,  several  tasks  throughout 
the  processing  cycle  may  run  in  parallel  while  processing  a 
particular  sector.  The  executive  determines  that  each  sector  is 
processed  in  a  step-by-step  manner  throughout  the  ATARS  process. 
At  the  same  time,  the  executive  program  controls  and  determines 
when  each  task  is  ready  to  accept  the  next  sector  for  processing 
as  critical  points  are  reached  in  the  task  sequencing.  The 
executive  program  handles  the  major  data  structures  (Table  3-2) 
for  the  tasks  by  providing  pointers  to  each  sector  of  data  in 
the  data  structure  and  by  placing  data  in  the  various  structures. 
This  keeps  the  data  segregated  according  to  sectors.  Care  must 
be  taken  by  the  executive  to  make  sure  that  data  structures  and 
lists  for  a  particular  sector  are  not  being  updated  and  read  at 
the  same  time.  A  mechanism  for  lockouts  must  be  implemented  to 
prevent  this  possibility. 

One  delay  is  required  during  the  task  sequencing  and  must  be 
implemented  by  the  executive.  This  delay  is  required  to  make 
sure  that  up-to-date  aircraft  positions  and  velocities  are  used 
when  determining  potential  conflicts  or  resolving  old  conflicts 
with  the  sector  being  processed.  This  delay  occurs  after  execu¬ 
tion  of  the  Aircraft  Update  Processing  Task  and  the  new  position 
in  the  data  base  has  been  established  for  the  aircraft  in  the 
sector.  (The  aircraft  are  ordered  in  the  data  base  according  to 
their  X-coordinate  in  order  to  expedite  processing  in  succeeding 
tasks.)  In  order  to  have  current  positions  for  aircraft  in  the 
two  adjacent  sectors,  further  processing  of  the  current  sector 
is  delayed  until  aircraft  in  the  next  two  sectors  have  been 
updated. 
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TIMING  WINDOWS  FOR  ATARS  FUNCTIONAL  PROCESSES 


TABLE  3-2 


MAJOR  DATA  STRUCTURES  FOR  ATARS  SECTOR  PROCESSING 


Surveillance  Input  Data  (Antenna  Sector) 

XINIT  List  (ATARS  Sector) 

X,  EX-Lists  (ATARS  Sector  Threading) 

Coarse  Screen  Pair  List  (Per  Sector) 

Resolution  Encounter  List  (Per  Sector)* 

Normal  Resolution  Encounter  List  (Per  Sector)* 
Delayed  Resolution  Encounter  List  (Per  Sector)* 
Proximity  Encounter  List  (Per  Sector)* 

Resolution  Deletion  Encounter  List  (Per  Sector)* 
Controller  Alert  List  (Per  Sector) 

Controller  Alert  List  Buffer  (Per  Sector) 
Deletion  List  (Per  Sector) 


*  See  Table  7-12  for  contents  of  these  data  structures 
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3.2  Sequencing  of  ATARS  Processing  Tasks 

Figure  3-1  presents  the  highest  level  flow  diagram,  which 
displays  the  sequencing  of  all  the  major  tasks  for  ATARS  sector 
processing.  The  major  delivery  points  for  the  input/output 
buffers  are  indicated  on  the  diagram.  The  numbers  in  the  boxes 
denote  critical  points  in  the  task  sequencing  where  several 
tasks  must  be  completed  before  starting  the  next  task.  It  is 
extremely  important  that  the  tasks  be  executed  in  the  order 
shown  in  Figure  3-1  for  each  sector  of  data.  Each  task  in  the 
sector  processing  sequence  has  a  defined  "window"  in  which  all 
computations  for  the  particular  sector  of  data  must  be  completed 
(see  Table  3-1).  The  individual  tasks  involve  other  routines 
which  are  necessary  to  complete  the  assignments  for  a  given  task 

The  following  discussion  describes  the  operation  of  the  ATARS 
sector  processing  at  the  highest  level  and  represents  the  perfor 
mance  of  all  tasks  on  data  from  one  ATARS  sector.  Through  the 
executive  control,  this  sector  process  is  applied  individually 
to  the  data  from  all  ATARS  sectors  in  the  manner  described  in 
Section  3.1. 

The  first  major  input  data  processor  is  the  Non-surveillance 
Data  Processing  Task  which  accepts  non-surveillance  data  from 
DABS  on  a  sector  basis  through  the  Non-surveillance  Buffer.  The 
messages  are  processed  once  per  sector  at  the  initiation  of 
report  processing.  These  messages  apply  only  to  DABS  aircraft 
and  do  not  contain  CIR  information.  The  output  of  the 
non-surveillance  task  is  added  to  the  aircraft  state  vectors  and 
conflict  tables  accordingly. 

The  second  major  input  data  processor  is  the  CIR  Processing 
Task.  CIR  information  is  received  through  the  CIR  Buffer.  The 
messages  are  processed  once  per  sector  at  the  initiation  of 
report  processing.  The  primary  function  of  the  CIR  processor  is 
to  examine  the  contents  of  the  CIR  of  aircraft  with  collision 
avoidance  avionics  equipage  each  time  this  data  is  downlinked 
and  to  update  the  information  in  the  ATARS  conflict  tables 
accordingly.  CIR  processing  notes  the  acceptance  of  resolution 
advisories  and  handoff  messages  uplinked  by  the  local  ATARS  site 
and  records  the  existence  of  resolution  advisories  and  handoffs 
generated  by  other  systems.  For  conflicts  involving  a 
controlled  aircraft,  the  CIR  Processing  Task  also  updates  the 
Controller  Alert  List  to  show  resolution  advisories  which  have 
actually  been  delivered  by  the  various  collision  avoidance 
systems. 
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The  third  major  input  data  processor  is  the  Report  Processing 
Task.  The  information  for  this  task  is  received  through  the 
Surveillance  Buffer  and  the  reports  are  processed  once  per 
sector.  A  decision  is  made  on  whether  the  reports  fall  inside 
the  ATARS  surveillance  area  and,  if  so,  DABS  and  ATCRBS  tracks 
are  initiated  with  an  aircraft  state  vector  and  added  to  the 
antenna  sector  list. 

A  fourth  task  which  processes  input  data  is  the  Incoming  Seam 
Pair  Request  Processing  and  Reply  Task.  The  data  for  this  task 
is  received  through  the  Remote  Site  Coordination  Buffer.  This 
buffer  operates  as  a  two-way  exchange,  providing  input  and 
accepting  outputs  from  this  task.  The  incoming  seam  pair  request 
task  processes  messages  received  over  ground  lines  from  neigh¬ 
boring  ATARS  sites.  These  messages  are  requests  for  conflict 
tables  involving  specified  pairs  of  aircraft.  This  task 
identifies  the  aircraft  in  the  request  and  returns  own-site's 
copy  of  the  conflict  tables,  if  any. 

After  report  processing  has  initiated  new  tracks  or  associated 
reports  with  existing  tracks,  the  Track  Processing  Task  performs 
track  updates  through  the  smoothing  and  prediction  algorithms. 

As  new  tracks  are  qualified  for  ATARS  service,  they  are  added  to 
an  aircraft  initiation  list  in  this  task.  These  aircraft  are 
then  added  to  the  ATARS  data  base  in  the  New  Aircraft  Processing 
Task.  The  new  aircraft  are  linked  into  the  data  base  to  be 
included  with  aircraft  in  the  ATARS  sector  for  which  they  are 
identified.  The  Track  Processing  Task  performs  the  final 
elimination  of  tracks  which  are  not  to  be  serviced  by  ATARS. 

Each  aircraft  in  the  sector  now  has  its  position  updated  to  a 
common  sector  time  in  the  Aircraft  Update  Processing  Task.  This 
is  necessary  because  track  reports  are  received  from  both  the 
local  sensor  and  other  remote  sensors  and  the  data  received  on 
all  aircraft  will  have  been  measured  at  different  times.  To 
eliminate  the  errors  that  might  be  introduced  into  the  ATARS 
calculations  by  dealing  with  data  measured  at  different  times, 
the  positions  of  all  aircraft  in  the  sector  will  be  time- 
adjusted  to  a  common  sector  time. 

The  area  near  the  radar  site  providing  the  surveillance  data  for 
ATARS  must  be  given  special  consideration  in  this  task  during 
sector  processing.  This  area  is  designated  the  hub  area  and  is 
defined  by  a  circle  of  radius  RHUB  (approx.  10  nmi)  from  the 
radar  site  (Figure  3-2).  The  position  of  all  aircraft  in  the 
area  must  be  updated  every  quarter  scan  (approx.  1.2  sec).  This 
is  necessary  in  sector  processing  because  data  is  processed  in 
sector  groups  and  a  small  position  change  in  the  area  may  move  an 
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RHUB  -  RADIUS  OF  HUB  PROCESSING  AREA 


FIGURE  3-2 

DIAGRAM  OF  HUB  PROCESSING  AREA  AS 
CONTAINED  IN  THE  ATARS  SERVICE  AREA 
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aircraft  one  or  more  sectors  from  its  last  sector  location. 

Thus,  an  updated  sector  identification  and  position  is 
maintained  for  aircraft  in  the  immediate  vicinity  of  the  radar 
site,  or  of  the  ATARS  area,  four  times  per  antenna  scan. 

Using  the  updated  data  base,  a  sector  of  aircraft  is  processed 
in  a  parallel  mode  by  the  following  three  tasks:  Coarse  Screen 
Processing  Task,  Conflict  Table  Seam  Addition  Task,  and  Terrain/ 
Airspace/Obstacle  Avoidance  Task. 

The  Coarse  Screen  Processing  Task  searches  the  data  base  for 
aircraft  that  are  potentially  in  conflict  with  this  sector  list 
of  aircraft.  This  search  is  implemented  through  the  use  of  two 
independent  doubly  linked  lists  which  are  ordered  on  the 
X-coordinates  of  the  aircraft.  Each  aircraft  is  contained  on 
one  list  or  the  other.  The  two  lists  are  maintained  in  order  to 
make  the  search  for  potential  conflict  pairs  more  efficient. 

All  aircraft  which  would  require  large  search  limits  because  of 
high  speeds  or  other  factors  are  placed  on  one  list  called  the 
EX-list  and  all  other  aircraft  are  placed  on  the  other  called 
the  X-list.  In  coarse  screening  one  individual  aircraft  is 
compared  with  its  neighbors  on  its  own  list  (and  possibly  with 
some  aircraft  on  the  other  list,  as  well)  to  find  a  pair  of 
potentially  conflicting  aircraft.  A  pattern  of  searches  has 
been  devised  that  avoids  duplicate  detection  of  potentially 
conflicting  pairs.  The  pairs  of  aircraft  which  are  identified 
are  entered  on  the  Coarse  Screen  Pair  List  for  this  sector. 

The  Conflict  Table  Seam  Addition  Task  examines  all  conflict 
tables  to  determine  whether  they  contain  any  aircraft  in  an 
ATARS  seam  in  this  sector  list.  Whether  an  aircraft  is  in  a 
seam  is  determined  by  the  Aircraft  Update  Processing  Task.  If 
this  aircraft  is  in  a  seam,  the  seam  flag  in  the  table  is  set. 

The  Terrain/Airspace/Obstacle  Avoidance  Task  has  the  capability 
to  provide  ati  alert  for  the  violation  of  restricted  airspace, 
close  proximity  to  the  terrain,  and  close  proximity  to  an 
obstacle.  This  task  operates  on  the  sector  list  of  aircraft  and 
only  affords  service  for  those  aircraft  in  the  ATARS  service 
area.  The  logic  to  determine  the  need  for  an  alert  is  provided 
in  this  task,  while  the  actual  construction  of  the  message  is 
performed  by  the  Data  Link  Message  Construction  Task  later  in 
the  sector  processing  sequence. 

Processed  in  parallel  with  the  above  three  tasks  is  the 
Controller  Alert  (Resolution  Notification)  Task.  This  task 
processes  all  pairs  on  the  Controller  Alert  List  for  the 
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sector.  It  deletes  pairs  not  updated  for  two  scans.  The 
controller  alert  logic  initially  sends  conflict  resolution  data 
for  pairs  in  conflict  and  later  sends  resolution  notices  for 
aircraft  which  have  received  resolution  advisories. 

The  Coarse  Screen  Pair  List  for  the  sector  is  used  by  the  Detect 
Task.  Detection  determines  if  a  conflict  situation  exists  for 
each  pair  on  the  list.  The  output  of  the  Detect  Task  is  a  group 
of  eight  flags  which  indicate  if  a  controller  alert,  proximity 
advisory,  threat  advisory  or  resolution  advisory  are  required. 

This  output  for  each  pair  identified  with  the  sector  number  is 
placed  in  one  of  the  following  lists:  Proximity  Encounter  List, 
Resolution  Deletion  Encounter  List,  or  Resolution  Encounter  List. 

Pairs  that  require  only  a  traffic  advisory  (no  resolution 
processing)  are  placed  on  the  Proximity  Encounter  List;  however, 
if  the  pair  was  previously  in  resolution  status,  it  is  placed 
instead  on  the  Resolution  Deletion  Encounter  List.  Pairs  on 
both  of  these  lists  are  input  to  the  Data  Link  Pre-processing 
Task  to  determine  the  correct  traffic  advisory.  The  Proximity 
Encounter  List  is  available  to  be  used  by  the  Data  Link  Message 
Pre-processing  (Proximity)  Task  as  soon  as  detection  places 
pairs  on  the  list.  Message  pre-processing  is  executed  in  three 
different  places  in  the  sequencing  of  tasks,  and  all  its  various 
functions  are  discussed  at  this  time.  The  Data  Link  Message 
Pre-processing  Task  creates,  updates,  and  deletes  entries  on  a 
list  maintained  for  each  subject  aircraft.  Entries  on  the  list 
contain  data  for  other  aircraft  which  are  in  conflict  with  the 
subject  aircraft. 

Pairs  which  are  currently  in  resolution  status  are  processed  by 
the  Master  Resolution  Task,  either  Normal  or  Delayed.  All  such 
pairs  are  then  input  to  the  Data  Link  Pre-processing  Task  to 
determine  the  corresponding  traffic  advisory.  Other  pairs  which 
would  qualify  for  resolution  status,  except  that  the  local  ATARS 
does  not  have  resolution  authority  under  the  multi-site 
protocol,  are  also  placed  on  the  Proximity  Encounter  List  as 
above. 

The  use  of  the  Resolution  Deletion  Encounter  List  for  the  sector 
is  delayed  after  the  completion  of  the  Detect  Task  until  the 
Conflict  Pair  Removal  Task  is  initiated.  This  task  is  discussed 
later  in  the  sequencing. 

The  Resolution  Encounter  List  for  the  sector  along  with  the 
results  of  the  Conflict  Table  Seam  Addition  Task  are  used  as 
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input  for  the  Seam  Pair  Task.  This  task  determines  own-site 
resolution  responsibility  for  each  pair  on  the  Resolution 
Encounter  List.  If  own-site  is  responsible  and  either  aircraft 
is  in  an  ATARS  seam,  the  task  places  the  pair  on  the  Delayed 
Resolution  Encounter  List.  The  Seam  Pair  Task  places  the  pair 
on  the  Normal  Resolution  Encounter  List  if  neither  aircraft  is 
in  a  seam.  Pairs  are  also  placed  on  the  Controller  Alert  List 
Buffer  at  this  time.  If  own-site  does  not  have  resolution 
responsiblity  but  CMDFLG  is  set,  the  pair  is  placed  on  the 
Proximity  Encounter  List  and  is  available  for  immediate 
processing  by  the  Data  Link  Message  Pre-processing  Task. 

The  Controller  Alert  List  Buffer  for  the  sector  is  used  by  the 
Controller  Alert  (Conflict  Resolution  Data)  Task  and  is 
available  for  processing  as  soon  as  the  entries  are  on  the 
list.  The  task  processes  pairs  on  the  Controller  Alert  List 
Buffer  and  initializes  or  updates  entries  on  the  Controller 
Alert  List.  When  each  entry  reaches  an  acceptable  confidence 
level,  a  Controller  Alert  Message  is  generated  containing 
conflict  resolution  data. 

The  Normal  and  Delayed  Resolution  Encounter  Lists  for  the  sector 
are  processed  in  parallel  by  the  Master  Resolution  (Normal)  Task 
and  the  Request  and  Process  Remote  Conflict  Tables  Task  respec¬ 
tively.  The  Master  Resolution  (Normal)  Task  provides  the 
framework  for  the  initial  selection  of  resolution  advisories, 
the  monitoring  of  the  conflict  to  adjust  advisories  to  more 
restrictive  or  less  restrictive  maneuvers  as  the  situation 
warrants,  the  staging  of  advisories  in  an  uncontrolled/controlled 
encounter,  and  the  recomputing  of  advisories  when  the  initial 
maneuvers  are  ineffective.  This  is  accomplished  through  the  use 
of  the  Normal  Resolution  Encounter  List,  pair  records,  and 
conflict  tables.  The  logic  for  providing  the  selection  of  the 
best  resolution  maneuver  for  a  pair  of  aircraft  given  the  current 
set  of  constraints  is  the  Resolution  Evaluation  Routine  which  is 
called  by  the  Master  Resolution  Task.  This  logic  performs  a 
fast-time  simulation  of  all  possible  sets  of  maneuvers  and 
selects  the  one  that  will  provide  the  greatest  safety  after 
considering  many  factors.  Some  of  these  factors  are  the 
separation  at  closest  approach,  the  turn  status  of  each 
aircraft,  the  likelihood  of  a  domino  conflict,  and  the  vertical 
and  horizontal  maneuver  performance  of  the  aircraft.  The  logic 
evaluates  multi-aircraft  situations  by  considering  the  current 
maneuver  constraints  when  determining  resolution  advisories  for 
a  new  conflict. 

The  Request  and  Process  Remote  Conflict  Tables  Task  requests  a 
copy  of  conflict  tables  from  all  neighboring  sites  involved  with 
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a  seam  pair.  The  reply  is  processed  to  add,  update,  or  delete 
from  the  own-site's  confict  tables  any  pair  record  which  is,  or 
was  previously,  controlled  by  the  neighboring  site.  This 
information  must  be  obtained  and  processed  before  the  Master 
Resolution  (Delayed)  Task  is  begun  for  the  sector. 

After  the  Master  Resolution  (Normal)  Task  updates  conflict 
tables,  the  Data  Link  Message  Pre-processing  Task  is  initiated 
for  the  pair.  The  functions  of  the  pre-processor  are  defined 
above  after  the  discussion  of  the  Detect  Task. 

Before  the  completion  of  the  Master  Resolution  (Normal)  Task, 
the  Master  Resolution  (Delayed)  Task  is  initiated  for  the 
sector's  aircraft  pairs  found  on  the  Delayed  Resolution  Encounter 
list.  The  Delayed  Master  Resolution  Task  provides  the  same 
service  to  the  aircraft  pairs  as  the  Normal  Master  Resolution 
Task.  The  updated  conflict  tables  are  afforded  processing  in 
the  Data  Link  Message  Pre-processing  Tasks  the  same  as  they  were 
after  normal  master  resolution  was  completed. 

At  the  completion  of  normal  and  delayed  master  resolution,  the 
Conflict  Pair  Removal  Task  is  initiated.  The  Conflict  Pair 
Removal  Task  has  the  general  purpose  of  ensuring  that  conflict 
pair  data  in  the  conflict  tables  is  closed  out  in  the  proper 
manner  when  it  is  no  longer  needed.  This  task  initiates  the 
uplink  of  null  resolution  advisories  for  conflicts  which  were 
resolved  by  the  local  site,  ensures  that  handoff  messages 
continue  to  be  uplinked  until  they  are  received,  and  deletes 
pair  records  whenever  it  is  made  possible  by  an  aircraft  flying 
out  of  the  local  site's  coverage  area.  Primary  input  to  the 
task  is  the  linked  list  of  conflict  tables. 

After  the  completion  of  the  Conflict  Pair  Removal  Task,  the 
State  Vector  Deletion  Task  is  initiated  for  the  sector.  This 
task  deletes  the  State  Vector  and  ends  tracking  of  an  aircraft 
which  leaves  the  ATARS/Domino  Mask.  If  the  aircraft  is  involved 
in  a  conflict,  an  entry  is  made  on  the  remote  list  of  aircraft. 

If  ATARS  has  unfinished  business  with  the  aircraft,  such  as  a 
message  indicating  handoff  status,  the  above  actions  are 
inhibited. 

At  the  completion  of  the  State  Vector  Deletion  Task,  the  Conflict 
Table  Seam  Delete  Task  is  initiated.  This  task  examines  all 
conflict  tables  to  see  if  any  tables  which  had  the  SEAM  flag  set 
no  longer  contain  any  aircraft  in  a  seam.  If  so,  SEAM  is  reset. 
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The  last  task  to  be  executed  in  the  sector  sequencing  is  the 
Data  Link  Message  Construction  Task.  This  task  processes  the 
sector's  list  of  aircraft  and  generates  all  messages  required 
for  each  aircraft.  The  task  reads  the  PWI  List  containing  all 
conflict  data  and  generates  conflict  messages  for  aircraft  in 
conflict.  If  the  aircraft  is  a  new  entry  in  the  ATARS  data 
base,  it  generates  a  message  containing  tracking  data.  If  the 
aircraft  is  in  restricted  airspace,  or  in  proximity  to  the 
ground  or  other  obstacles,  it  generates  a  message  containing 
warning  data. 

3.3  External  Interfaces 


The  ATARS  external  interfaces  go  through  the  DABS  sensor.  Even 
though  ATARS  sends  messages  to  ATC  facilities,  aircraft  and 
other  sites,  and  receives  messages  from  these  sources,  all 
communications  are  handled  through  the  local  DABS  sensor.  The 
exact  physical  character  of  the  interfaces  and  the  buffer 
formats  between  DABS  and  ATARS  are  found  in  Reference  1 .  The 
contents  of  the  report  formats  are  discussed  in  this  section  for 
c  larif ication. 

A  diagram  of  the  ATARS-SENSOR  interface  is  illustrated  in  Figure 
3-3.  Note  that  some  of  the  information  flows  in  one  direction 
only  (DABS-to-ATARS,  ATARS- to-DABS)  and  the  remainder  flows  in  a 
two-way  buffer.  The  ATARS  buffers  noted  in  the  diagram  are 
serviced  by  the  appropriate  task. 

The  input-only  information  from  the  DABS  sensor  to  ATARS 
consists  of  reports  in  the  following  three  buffers: 

1.  CIR  Buffer 

2.  Surveillance  Buffer 

3.  Non-surveillance  Buffer 

These  buffers  are  written  by  the  DABS  sensor  and  read  by  ATARS. 
They  are  two-segment  buffers  with  one  segment  being  written  at 
the  same  time  that  the  other  segment  is  read.  Overwriting  a 
segment  which  is  being  read  must  be  prevented  by  a  lockout  flag 
or  by  careful  program  timing. 

Input  data  for  all  three  buffers  is  transmitted  in  blocks 
consisting  of  all  the  surveillance,  CIR  or  message  reports 
available  to  the  local  sensor  (local  or  remote  reports)  during 
one  11  1/A  degree  sector  of  local  antenna  rotation.  A  single 
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LINK  MESSAGE  BUFFER  -  DATA  LINK  MESSAGE  CONSTRUCTION  OUTPUT 
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FIGURE  3-3 

ATARS-SENSOR  INTERFACE  DIAGRAM 


completion  interrupt  is  then  given  to  the  ATARS  processor.  Just 
before  the  interrupt,  a  special  header  word  is  filled  in  each 
Surveillance  Buffer  with  the  current  local  sector  identification 
number  and  sector  time  (see  Figure  3-4). 

The  Surveillance  Buffer  contains  reports  utilized  by  the  ATARS 
Track  Processing  Task.  The  local  or  remote  reports  are 
disseminated  to  ATARS  using  the  formats  given  in  Table  3-3  for 
DABS  and  Table  3-4  for  ATCRBS  reports.  These  reports  are 
outputs  of  the  DABS  sensor  tracker  correlator;  uncorrelated 
reports  do  not  occur.  These  reports  are  accepted  in  their 
entirety,  as  ATARS  is  a  non-correlating  user  of  DABS. 

The  CIR  Buffer  contains  all  the  CIR  information  which  has 
accumulated  during  the  time  represented  by  the  rotation  of  the 
sensor  antenna  through  one  sector.  The  CIR  Buffer  contents  are 
read  by  the  CIR  Processing  Task  and  the  information  is  passed 
along  to  the  appropriate  ATARS  tasks. 

The  Non-surveillance  Buffer  contains  all  messages  which  have 
accumulated  during  the  time  represented  by  the  rotation  of  the 
sensor  antenna  through  one  sector.  The  formats  of  these 
messages  are  indicated  in  Section  5. 

The  output-only  information  from  ATARS  to  the  DABS  sensor 
consists  of  reports  in  the  following  two  buffers: 

1.  Uplink  Message  Buffer 

2.  Non-surveillance  Buffer 

The  ATARS  messages  generated  for  the  aircraft  through  the  Data 
Link  Message  Construction  Task  are  delivered  to  the  Uplink 
Message  Buffer.  All  the  data  link  capability  requests, 
start/stop  ATARS  service,  and  BCAS  squitter  lockout  are 
delivered  to  the  Non-surveillance  Buffer. 

The  two-way  buffers  provide  information  from  ATARS-to-DABS  and 
from  DABS-to-ATARS.  These  two-way  reports  are  transferred  in 
the  following  buffers: 

1.  Function  Status  Buffer 

2.  ATC  Coordination  Buffer 

3.  Remote  Site  Coordination  Buffer 
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FIGURE  3-4 

SURVEILLANCE  BUFFER  DATA  STRUCTURE 
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TABLE  3-3 


DABS  REPORT  FORMAT* 


Fields 


Length  (Bits) 


Test  1 
Format  Type  2 
Radar  Substitution  1 
Cone  of  silence  flag  set  in  local  sensor  1 
Mode  C  not  decoded  1 
Altimeter  correction  8 
Sensor  Priority  Status  1 
Primary  Coordination  in  Progress  1 
Radar  Reinforced  1 
Code  7700  1 
Code  7600  1 
Radar  Only  1 
Alert  1 
Control  status  1 
Reply  Type  3 
Null  Report  1 
Track  Start  1 
Track  Drop  1 
Range**,  LSB  =  1  Ru  (1/16  us)  16 
Azirautn,  LSB  =  1  Au  (0.022°)  14 
Mode  C  altitude,  LSB  -  100  feet  12 
DABS  ID  24 
Sensor  ID  4 
Site  ID  Bits  4 
Measurement  time,  LSB  -  1/16  second  8 
Primary/Secondary  status  1 
Diffraction  Zone  flag  1 


*  The  exact  form  of  this  data  is  provided  in  Reference  1. 

**  This  is  a  two-way  range  expressed  in  units  of  time. 
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TABLE  3-4 


ATCRBS  REPORT  FORMAT* 


Fields _ Length  (Bits) 


Test  1 
Format  Type  2 
Radar  Substitution  1 
Cone  of  silence  flag  set  in  local  sensor  1 
Mode  3/A  present  1 
Mode  C  present  1 
Altimeter  correction  8 
Mode  C  not  decoded  1 
SPI  (IDENT)  1 
Radar  Reinforced  1 
Code  7700  1 
Code  7600  1 
Radar  Only  1 
False  target  flag  1 
Null  Report  1 
Track  Start  1 
Track  Drop  1 
Range**,  LSB  =  1  Ru  (1/16  us)  16 
Azimuth,  LSB  =  1  Au  (0.022°)  14 
Mode  C  altitude,  LSB  =  100  feet  12 
Mode  3 /A  12 
ATCRBS  Surveillance  File  No.  12 
ATCRBS  code  in  transition  1 
Sensor  ID  4 
Measurement  time,  LSB  =  1/16  second  8 
Control  Status  1 
Diffraction  Zone  Flag  1 


*  The  exact  form  of  this  data  is  provided  in  Reference  1. 

**  This  is  a  two-way  range  expressed  in  units  of  time. 
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The  Function  Status  Buffer  delivers  ATARS  status  to  DABS  and 
local  sensor  status  to  ATARS.  The  ATC  Coordination  Buffer 
delivers  Controller  Alert  Messages  from  ATARS  to  DABS  for  the 
ATC  facilities  and  remote  sensor  status  from  DABS  to  ATARS.  The 
Remote  Site  Coordination  Buffer  delivers  ATARS  requests  for 
remote  site  seam  pairs  to  DABS  and  requests  for  local  site  seam 
pairs  to  ATARS  from  DABS.  The  Remote  Site  Buffer  also  delivers 
the  start/stop  request  for  remote  CIR  data. 

3.4  Aircraft  State  Vector 


The  aircraft  state  vector  used  by  the  ATARS  processor  is 
presented  in  Table  3-5.  The  state  vector  contains  all  the  known 
information  for  a  particular  aircraft  that  is  being  tracked  by 
ATARS.  The  data  is  listed  in  the  table  under  four  categories: 

1.  Tracker  Data 

2.  Pointer  Parameters 

3.  Flag  Parameters 

4.  Numerical  Parameters 

T^e  nomenclature  for  each  data  parameter  may  be  used  in  this 
document  with  the  number  1  or  2  added  as  a  suffix  (e.g.,  XDE, 
XDE1 ,  XDE2).  When  the  parameter  appears  without  the  numerical 
suffix,  a  single  aircraft  is  being  addressed  in  the  discussion. 
In  such  a  single  aircraft  situation,  parameters  may  also  appear 
with  a  1  as  a  suffix.  When  two  aircraft  are  being  compared,  it 
is  necessary  to  identify  the  parameters  from  each  aircraft's 
state  vector.  To  do  this,  a  1  is  added  to  the  subject  aircraft' 
state  vector  parameters  and  a  2  is  added  to  the  object  aircraft' 
state  vector  parameters. 

The  individual  aircraft  state  vectors  are  placed  in  a  file 
called  the  Central  Track  Store  (CTS).  The  CTS  is  a  convenient 
location  to  access  all  tracks  for  the  ATARS  processor.  Detailed 
information  for  the  CTS  usage  is  found  in  Section  4.3. 

3.5  En  Route  Operation 

ATARS  is  required  to  provide  service  in  en  route  areas  as  well 
as  terminal  areas.  Certain  characteristics  of  the  en  route 
environment  require  that  the  ATARS  system  operating  in  the  en 
route  area  differ  slightly  from  that  in  the  terminal  area.  The 
body  of  this  document  addresses  the  ATARS  system  in  a  terminal 
area.  This  section  describes  the  ways  in  which  ATARS  in  the  en 
route  area  differs. 
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TABLE  3-5 


Nomenclature 

X 

Y 

Z 

XP 

YP 

ZP 

XPI 

YPI 

XD 

YD 

ZD 

XDE 

YDE 

ZDE 

XDI 
YD  I 

VSQ 

FIRM! 

FIRME 

FIRMZ 

RHOP 

AZP 

TM 

TMZ 

TMR 

TMP 

TD 


STATE  VECTOR 

TRACKER  DATA 


Meaning 

X  position  of  aircraft 

Y  position  of  aircraft 
Z  position  of  aircraft 

External  -one  scan  predicted  X  position 
External  one  scan  predicted  Y  position 
External  one  scan  predicted  Z  position 

Internal  one  scan  predicted  X  position 
Internal  one  scan  predicted  Y  position 

X  velocity  of  aircraft 

Y  velocity  of  aircraft 
Z  velocity  of  aircraft 

External  X  velocity  estimate 
External  Y  velocity  estimate 
External  Z  velocity  estimate 

Internal  X  velocity  estimate 
Internal  Y  velocity  estimate 

Square  of  the  horizontal  speed  estimate,  XDl2  +YDl2 

Internal  firmness  level 
External  firmness  level 
Altitude  firmness  level 

Predicted  range  of  track  at  next  data  correlation  time 
Predicted  azimuth  of  track  at  next  data  correlation  time 

Time  of  last  reported  Range/Azimuth  data 
Time  of  last  reported  Altitude  data 

Time  of  current  remote  Range/Azimuth,  Altitude  data 

Expected  time  of  next  local  data 

Approximate  time  at  which  ATARS  message  was  received  by 
aircraft 
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TABLE  3-5 


Nomenclature 

ACMES 

ATCREF 

CTE 

CTPTR 

CUROWN 

LSTOWN 

NEXTA 

NEXTS 

NEXTX 

PREVX 

PWPTR 

STKPTR 

UPMES 


STATE  VECTOR 
(Continued) 


POINTERS 

Meaning 

Pointer  to  last  set  of  ATARS  messages  successfully 
delivered  to  aircraft 

Pointer  to  entry  in  CREFX  for  ATCRBS  aircraft 

Pointer  to  conflict  table  entry  for  this  aircraft 

Pointer  to  head  of  the  conflict  table  which  contains 
table  entry  for  this  aircraft 

Pointer  to  current  Own  Message  data 

Pointer  to  last  successfully  delivered  Own  Message  data 

Pointer  to  the  following  aircraft  in  the  ATARS  sector 
list  thread 

Pointer  to  the  next  aircraft  in  the  antenna  sector  list 
thread 

Pointer  to  the  next  aircraft  in  the  X-list  or 
EX- list  thread 

Pointer  to  the  previous  aircraft  in  the  X-list  or 
EX- list  thread 

Pointer  to  list  of  PWI's  for  aircraft 

Pointer  to  the  stack  of  three  positions,  velocities  and 
times  used  for  turn  rate  computation 

Pointer  to  last  set  of  ATARS  messages  released  to  uplink 
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STATE  VECTOR 
(Continued) 


FLAGS 


Nomenclature 


Meaning 


ATSS  Flag  indicating  that  aircraft  is  ready  for  ATARS  service 

(i.e.,  it  is  in  the  XINIT  list) 

BCLO  Flag  indicating  BCAS  lockout  condition 

CENTR  Flag  that  indicates  this  aircraft  is  in  the  center  area 

of  the  ATARS  service  area 

DELFG  Flag  to  identify  the  state  vector  of  an  aircraft  to  be 

deleted 

DLOUT  Flag  that  indicates  that  local  sensor  lost  data  link 

contact  with  aircraft  on  most  recent  scan 

DRATS  Flag  indicating  that  this  aircraft  was  dropped  by  the 

ATARS  tracker 

DRSUR  Flag  indicating  that  this  aircraft  was  dropped  by  the 

sensor 

EXFLG  Flag  that  indicates  whether  aircraft  is  linked  on  X-list 

or  EX-list  of  pointers 

HUBFLG  Flag  to  indicate  that  aircraft  is  in  a  zone  close  to  the 

antenna  and  needs  special  position  processing 

INXFL  Flag  for  new  aircraft  on  the  XINIT  list 

LOFL  Flag  indicating  that  this  aircraft  has  local  data 
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TABLE  3-5 


STATE  VECTOR 
(Continued) 

FLAGS  (Concluded) 

Nomenclature 

Meaning 

OBAFLG 

Flag  indicating  that  an  Obstacle  Avoidance  Message  is 
required  this  scan 

OSCFL 

Flag  indicating  that  RETCIR  will  be  reset  after  one  scan 

RESFLG 

Flag  to  indicate  restricted  airspace  alert 

RMFL 

Flag  indicating  that  this  aircraft  has  remote  data 

SMPR 

Flag  indicating  that  this  aircraft's  data  has  been 
smoothed  and  predicted  this  scan 

SPIDFG 

Flag  set  for  all  signpost  state  vectors  for  identifi¬ 
cation  in  coarse  screen 

SPRO 

Antenna  sector  processing  flag 

TCAFLG 

Flag  to  indicate  TCA  alert 

TRAFLG 

Flag  indicating  that  a  Terrain  Avoidance  Message  is 
required  this  scan 

XUPFL 

Flag  to  prevent  multiple  updates  when  editing  X-list/ 
EX-list  of  pointers 
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TABLE  3-5 


Nomenc lature 

ACAT 

ATSEQ 

CODE 

CUNC 

FAZ 

FILE 

GEOG 

HMS 

PSTAT 

RASFLG 

REMCIR 

RETCIR 

SVSID 

SLREPS 

TURN 


STATE  VECTOR 
(Continued) 


NUMERICAL  DATA 
Meaning 


Aircraft  area  type 

ATARS  equipped,  BCAS  and  ATARS  equipped,  or  neither 
(unequipped) 

DABS  Code  or  latest  3/A  Code 

Status  variable  indicating  whether  aircraft  is  controlled 
or  uncontrolled 

Final  Approach  Zone  indicator 

ATCRBS  surveillance  file  number;  not  used  for  DABS 

The  geographical  zone  of  the  aircraft 

Horizontal  maneuver  status,  used  in  the  X-Y  tracker 

Indicator  that  tells  local  site's  primary /secondary 
status  with  respect  to  this  aircraft 

Indicator  that  a  Restricted  Airspace  Avoidance  or  TCA 
Alert  Message  is  required  this  scan. 

Identity  of  remote  site  from  which  CIR  data  will  be  (if 
negative)  or  is  being  (if  positive)  requested 

Identity  of  remote  site  to  whom  CIR  data  is  being 
re  turned 

Sector  identity  of  the  aircraft  used  to  group  a  set  of 
aircraft  in  a  sector 

Slant  range  from  sensor  providing  the  most  recent 
surveillance  report 

Horizontal  maneuver  status,  used  in  Detect  and  Master 
Resolution  Tasks 
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Nomenclature 

TYPE 

ZPRT 


TABLE  3-5 

STATE  VECTOR 
(Concluded) 


NUMERICAL  DATA  (Concluded) 
Meaning 


Status  variable  indicating  whether  the  aircraft  is  DABS, 
INDABS  or  ATCRBS 

Call  letters  of  airport  associated  with  Final  Approach 
Zone  (FAZ) 


Data  blocks  for  storing  DABS  or  ATCRBS  reports  described 
in  Table  3-3  or  Table  3-4 


3.5.1  ATARS  Operation  With  Back-To-Back  DABS  Antenna 

DABS  sensors  are  to  be  installed  at  sites  where  current  ATC  en 
route  radars  are  in  operation  and  are  to  be  operated  in 
conjunction  with  the  en  route  primary  radars.  The  primary 
radars  operate  with  a  scan  time  of  10  to  12  seconds.  If  the 
DABS  sensor  were  required  to  operate  with  a  data  rate  corres¬ 
ponding  to  this  scan  time,  the  ATARS  service  that  could  be 
provided  would  be  unacceptable.  To  improve  the  ATARS  service, 
the  DABS  sensor  has  been  designed  to  operate  with  a  back-to-back 
antenna  (an  antenna  with  two  faces  directed  180  degrees  apart) 
rotating  with  a  scan  time  of  10  to  12  seconds.  The  effective 
data  update  interval  is  then  5  to  6  seconds. 

The  operation  of  the  DABS  sensor  with  the  back-to-back  antenna 
is  described  in  Reference  1.  The  modifications  to  the  normal 
ATARS  algorithms  that  are  required  for  operation  with  the 
back-to-back  antenna  are  described  in  this  section.  The 
remainder  of  this  document  describes  algorithms  for  operation 
with  a  normal  DABS  sensor  (scan  time  on  the  order  of  4.7 
seconds) . 

A  sector  will  still  be  defined  as  a  sweep  of  11  1/4  degrees. 

When  an  input  completion  interrupt  is  received,  data  for  two 
sectors  will  be  passed  through  the  Surveillance  Buffer.  This 
data  will  be  the  data  collected  from  the  front  face  and  the  back 
face  of  the  antenna  while  the  antenna  rotated  through  11  1/4 
degrees.  The  two  sectors  represented  are  180  degrees  apart. 

The  data  from  both  sectors  will  be  serviced  by  the  report 
processing  algorithms.  Sector  header  data  will  be  provided  for 
each  sector  of  data. 

One  change  to  be  made  when  ATARS  is  operated  with  a  back-to-back 
antenna  is  the  time  at  which  second-pass  processing  is  performed 
in  the  Track  Processing  Task.  Second-pass  processing  is  normally 
done^in  sector  n-20.  With  the  back-to-back  antenna,  it  should 
be  done  in  sector  n-12.  This  change  is  made  so  that  the 
processing  of  remote  data  (which  now  occurs  four  times  per  scan 
instead  of  the  normal  two)  will  occur  at  times  equally  distri¬ 
buted  throughout  the  scan,  and  so  that  all  operations  in  a  given 
sector  on  data  from  the  front-face  of  the  antenna  (including 
resetting  of  the  smooth/predict  and  report  process  flags)  will 
be  complete  before  any  operations  with  data  from  the  back-face 
will  be  started  for  that  sector.  The  tasks  performed  during 
second-pass  processing  will  not  be  changed  in  any  way;  only  the 
time  of  performing  second  pass  processing  is  changed. 
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The  sector  processing  executive  logic  must  be  modified  so  that 
the  sector  list  of  aircraft  from  each  face  of  the  antenna  can  be 
processed  as  a  separate  stream.  When  the  antenna  enters  a  new 
sector,  the  ID's  of  both  the  front-face  and  the  back-face  sectors 
will  be  added  to  the  sector  request  stack.  The  sectors  will 

then  be  processed  as  separate  streams  through  the  ATARS  logic. 

The  time  allowed  to  complete  each  processing  task  must  be 
adjusted  so  that  advisories  detected  on  the  front-face  of  the 
antenna  will  be  available  for  uplink  on  the  next  sweep  of  the 
back-face  of  the  antenna.  The  primary  radar  associated  with  an 
en  route  DABS  sensor  will  have  only  one  antenna  face.  This  face 

will  be  matched  with  the  front-face  of  the  DABS  sensor  antenna. 

Hence,  radar-only  tracks  will  be  processed  once  per  scan.  It  is 
necessary  to  have  antenna  position  reports  supplied  to  ATARS 
once  per  sector  for  only  the  front-face. 

In  prediction,  with  the  back-to-back  antenna,  positions  should 
be  predicted  to  the  time  of  next  expected  data.  This  will  be  a 
prediction  over  a  half  scan  rather  than  a  full  scan.  ATARS  will 
be  able  to  deliver  resolution  advisories  on  the  uplink  on  either 
the  front-face  beam  or  the  back-face  beam. 

3.5.2  Modification  of  ATARS  Detection  Parameters 

Another  characteristic  of  the  en  route  area,  in  addition  to  the 
slower  scan  rate,  is  the  operation  with  larger  aircraf t-to-sensor 
ranges  and  a  resultant  reduction  in  position  and  velocity 
tracking  accuracy.  To  provide  acceptable  operation  at  larger 
ranges,  ATARS  must  use  increased  conflict  detection  parameters. 
Currently,  ATARS  tests  the  aircraft  in  a  pair  before  selecting  a 
set  of  detection  parameters  for  that  pair.  If  either  aircraft 
is  outside  a  specified  area,  the  detection  parameters  for  that 
pair  are  increased.  Additional  parameters  that  are  specifically 
related  to  the  en  route  environment  will  be  supplied  in  the 
future. 
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4.  SURVEILLANCE  DATA  AND  TRACK  PROCESSING 


4.1.  General  Requirements 

ATARS  surveillance  processing  may  be  divided  into  three  main 
subfunctions:  input  processing,  track  processing,  and  smoothing/ 

prediction.  The  general  division  of  responsibility  is  that  input 
processing  accepts  target  reports  from  DABS  sensor  processor  and 
screens  and  prepares  them  for  tracking.  Track  processing  main¬ 
tains  a  file  of  system  tracks  and  selects  particular  target 
reports  for  track  update.  Smoothing  and  prediction  utilizes  the 
selected  reports  for  production  of  fresh  position  and  velocity 
updates . 

ATARS  surveillance  processing  is  required  to  track  those  DABS 
and  ATCRBS  Mode  C  equipped  aircraft  which  are  being  tracked  by 
the  local  sensor  in  the  ATARS  service  area.  ATCRBS  aircraft 
without  Mode  C  or  outside  the  area  are  not  tracked. 

4.2  Coordinate  Systems 

Target  reports  are  received  in  the  rho,  theta,  h  (slant  range, 
azimuth,  altitude)  system  of  the  DABS  sensor.  ATARS  maintains 
and  uses  track  estimates  in  a  modified  Cartesian  X,  Y,  Z  system. 
The  local  sensor  lies  at  the  center  of  the  X,  Y  grid  with  X  east 
and  Y  north  (see  Figure  4-1). 

Mapping  between  these  two  systems  is  based  on  a  flat  earth 
assumption.  Under  this  assumption  X,  Y  are  considered  as  the 
ground  plane  projection  coordinates  of  an  aircraft,  while  Z  is 
identical  to  the  altitude.  However,  because  of  the  actual 
curvature  of  the  earth,  the  X,  Y,  Z  which  are  so  computed  do 
not  exactly  correspond  to  the  aicraft  position  in  a  physical 
Cartesian  space.  Nevertheless,  the  X,  Y,  Z  descriptions 
produced  by  this  formal  mapping  will  be  utilized  throughout  the 
ATARS  processing.  The  equations  of  the  mapping  are  shown  in  the 
figure . 

Geographical  corrections  take  place  in  rho,  theta.  Reports 
selected  for  track  update  are  coordinate  converted  to  the  X,  Y, 

Z  system  before  using  them  to  smooth  the  track  estimate.  The 
inverse 

mapping  is  used  to  determine  a  predicted  rho,  theta  for  the  next 
correction  and  for  antenna  sector  update. 

In  converting  remote  reports  to  local  X,  Y,  Z  coordinates,  any 
method  of  calculation  may  be  used  which  accurately  accounts  for 
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FIGURE  4-1 

ATARS  TRACK  SECTORIZATION  AND  COORDINATES 
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the  real  spatial  geometry.  In  order  to  be  useful  in  tracking, 
the  truncation  errors  in  conversion  must  be  kept  comparable  to 
the  random  data  error  (i.e.,  approx.  =  100  feet  or  less).  The 
method  should  be  reasonably  efficient,  but  since  remote  report 
conversion  will  only  be  occasionally  required,  some  complexity 
can  be  tolerated. 

4.3  Major  Files 

The  ATARS  track  file  is  a  separate  creation  of  the  ATARS  function 
and  is  not  identical,  either  physically  or  in  content,  to  the 
DABS  sensor  track  file.  This  file  (the  Central  Track  Store 
(CTS))  consists  of  a  block  of  track  slots,  of  sufficient  size  to 
accommodate  the  maximum  track  load.  Each  slot  may  either  be 
empty  or  it  may  contain  track  information  (aircraft  state  vector) 
about  a  particular  aircraft.  In  addition,  a  number  of  slots  of 
known  fixed  X  coordinate  distance  called  signposts  provide  quick 
points  of  entry  into  the  appropriate  X-list  as  described  in 
Section  6.4.  Signposts  are  bookkeeping  aids  and  are  not  altered 
by  the  tracking  programs. 

A  CTS  file  is  used  to  transmit  information  for  a  particular 
aircraft  throughout  the  various  tasks  in  the  ATARS  processing 
cycle.  The  central  track  store  contains  three  basic  categories 
of  information:  position,  velocity,  time  estimates;  status  and 
ID  indicators;  and  control  flags. 

The  tracks  in  CTS  must  be  rapidly  accessible  in  two  ways  for 
Report  Processing  and  Track  Processing  Tasks:  on  a  geographical 
antenna  sector  basis  and  by  aircraft  ID.  32  fixed  azimuth 
sectors  are  defined  with  respect  to  the  local  sensor,  beginning 
clockwise  from  north  (see  Figure  4-1).  Each  antenna  sector  is 
11  1/4  degrees  wide.  Tracks  are  organized  (e.g.,  by  threading) 
so  that  the  ATARS  tracker  can  efficiently  index  and  process 
tracks  lying  in  a  particular  antenna  sector.  Since  the  aircraft 
move,  their  antenna  sector  assignements  will  change.  These 
changes  are  monitored,  and  an  updated  antenna  sector  organization 
is  maintained. 

Rapid  access  of  individual  tracks  through  their  ATCRBS  surveil¬ 
lance  file  number  or  DABS  ID  is  accomplished  by  establishing  a 
cross-re ference  file  for  each  of  these  aircraft  classes.  These 
files  which  are  denoted  CREFA  and  CREFD,  respectively,  relate 
the  input  code  (which  may  be  compressed  by  hashing)  to  the  corre¬ 
sponding  track  slot  number  in  CTS.  When  tracks  are  dropped  or 
new  tracks  are  started,  the  cross-reference  files  are  corre¬ 
spondingly  updated.  These  file  relations  are  indicated  in 
Figure  4-2. 


Since  the  ratio  of  ATCRBS  to  DABS  track  loads  is  an  environ¬ 
mental  variable,  it  is  desirable  that  CTS  not  be  partitioned  in 
any  fixed  way  between  these  two  track  classes.  Procedures  for 
organizing  and  accessing  CTS  should  remain  efficient  regardless 
of  this  load  ratio. 

4.4  Report  Processing 

The  ATARS  surveillance  processing  initiates  and  maintains  ATARS 
tracks  on  all  DABS  and  ATCRBS  Mode  C  beacon  equipped  aircraft  in 
the  ATARS  surveillance  area  which  are  being  tracked  by  the  DABS 
sensor.  This  objective  is  accomplished  by  two  major  tasks: 
Report  Processing  Task,  discussed  in  this  section,  and  Track 
Processing  Task,  discussed  in  Section  4.5. 

Report  processing  operates  on  interrupt  after  all  target  reports 
for  a  new  antenna  sector  have  arrived  in  the  surveillance  input 
buffer.  The  surveillance  inputs  consist  of  target  reports  from 
the  DABS  sensor. 

Input  data  are: 

1.  a  sector  header  antenna  azimuth  word, 

2.  target  reports  from  surveillance  buffer. 

The  services  performed  are  to: 

1.  update  current  antenna  position  and  rate  estimates, 

2.  screen  local  reports  and  reject  all  reports  falling 
outside  the  ATARS  surveillance  area. 

3.  Correlate  local  and  remote  reports  with  tracks  through 
DABS  ID  or  ATCRBS  file  number  cross-references.  Store 
reports  with  the  state  vectors  in  CTS. 

4.  Start  new  DABS  or  ATCRBS  tracks. 

5.  Flag  tracks  for  drop  (if  indicated  by  sensor). 

A  general  flow  chart  for  the  Report  Processing  Task  is  shown  in 
Figure  4-3. 

Notes  on  the  logic: 

I.  The  antenna  position/rate  update  routine  is  outlined  in 
Section  4.7. 
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2.  The  ATARS  service  area  is  subtended  by  a  larger  area, 
defined  by  a  rho,  theta  map.  This  map  is  defined  as  a 
convex  figure  encompassing  the  ATARS  domino  surveillance 
area  as  shown  in  Figure  4-4.  Since  the  surveillance  area 
is  a  convex  figure,  it  suffices  to  define  a  map  with  a 
minimum  and  maximum  rho  for  each  theta  (or  theta  interval). 
Two  maps  are  required,  one  for  reports  above  an  altitude 
HZONE  and  one  below  this  altitude  (see  Section  6.3).  In 
order  to  pass  the  screen,  a  local  report  with  altitude  data 
must  lie  within  the  area  appropriate  for  that  altitude.  If 
no  altitude  has  been  measured,  then  it  must  lie  within  at 
least  one  of  the  two  map  areas.  (Remote  reports  cannot  be 
mapped  out  efficiently  here  because  their  rho,  theta  are 
not  local  coordinates.) 

3.  When  a  local  report  passes  area  screening,  and  a  remote 
report  is  not  a  null  report,  the  DABS  ID  or  ATCRBS  file 
number  is  used  to  find  the  associated  track  in  CTS  (if 
any).  The  cross-reference  files  CREFD,  CREFA  provide  the 
required  links.  If  the  track's  drop  flag  (DRSUR)  is  set, 
it  cannot  accept  further  data  and  the  report  is  ignored. 
Further,  a  local  report  must  pass  a  rho,  theta  reasona¬ 
bility  check  of  measured  vs.  predicted  coordinates  in  order 
to  merit  further  consideration.  The  report  is  then  stored 
in  the  CTS  report  storage  area. 

4.  When  a  local  report  is  a  null  report,  the  NULLFG  is  set 
to  indicate  to  the  Track  Processing  Task  that  this  partic¬ 
ular  track  is  to  be  treated  as  a  "miss"  rather  than  a  "hit". 
If  the  Diffraction  Zone  Bit  (DZB)  is  set  in  the  report,  the 
track  is  also  processed  as  a  "miss". 

5.  When  a  remote  report  is  stored,  the  remote  measurement 
time  (TMR)  is  computed  as  the  current  clock  time  (TCLOCK) 
minus  the  report  storage  delay  time  (TDELA  -  as  supplied 
with  the  report)  and  also  stored.  The  remote  flag  is  set. 

When  a  local  report  is  stored,  the  local  data  flag  is  set. 
Measurement  time  computation  is  done  elsewhere  (Track 
Update  Routine). 

6.  For  local  reports  associated  with  a  track,  the  track 
drop  bit  is  examined.  If  set,  the  track  drop  flag  (DRSUR) 
is  set. 

Track  drops  can  be  initiated  here,  with  a  report  drop  bit 
indication,  or  later  in  Track  Update  Routine  (Section  4.5.1) 
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FIGURE  4-9 

REPORT  PROCESSING  TASK  IPogo  1  of  2) 
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FIGURE  4-3 

REPORT  PROCESSING  TASK  (PAGE  2  OF  2) 


when  data  has  been  missing  too  long  or  the  track  is  out  of 
the  ATARS  service  area.  The  State  Vector  Deletion  Task 
performs  the  final  drop  action  for  tracks  which  have  been 
in  ATARS  coverage. 

7.  Track  starts  are  solely  a  report  processing  function. 
They  occur  when  a  local  report  is  examined  which  does  not 
have  an  existing  associated  track.  The  report  is  tested 
further  to  determine  that: 

a.  The  drop  bit  is  not  set. 

b.  Altitude  data  (Mode  C)  is  available. 

c.  The  indicated  altitude  is  reasonable. 

If  these  conditions  are  satisfactory,  the  Track  Initiali¬ 
zation  Routine  (Section  4.4.1)  is  utilized  to  begin  a  new 
track;  otherwise,  the  report  is  ignored. 

The  Track  Initialization  Routine  is  shown  in  Figure  4-5.  Track 
initiation  occurs  only  through  local  beacon  reports  and  is 
started  with  a  single  beacon  report. 

The  following  services  are  performed: 

1.  Find  an  empty  track  slot  in  CTS.  Empties  are  threaded 
together  into  their  own  list  using  the  sector  thread 
mechanism.  This  slot  will  hold  the  new  track  state  vector. 

2.  Determine  and  store  this  report's  measurement  time. 

3.  Convert  the  report  coordinates  to  X,  Y,  Z.  Determine 
and  store  the  initial  horizontal  prediction  estimates  for 
external  and  internal  positions,  and  velocities.  Determine 
and  store  the  initial  predicted  rho,  theta  search  position. 

The  initial  internal  and  external  position  predictions  are 
set  identical  to  the  reported  positions.  Set  the  velocities 
to  a  small  non-zero  value.  Turn  rate  stack  is  initialized 
for  the  track  to  be  used  in  X,  Y  Smoothing  Routine. 

4.  Determine  the  antenna  sector  in  which  this  track  lies 
and  add  it  to  the  proper  antenna  sector  list  (with  forward 
threading  only). 

5.  Initialize  the  horizontal  firmness  (firmness  control 
explained  in  Section  4.5.2)  and  the  turn  indicator. 


4-10 


Figure  4-s 

TRACK  INITIALIZATION  ROUTINE  (P»g« 


6.  Calculate  the  ATARS  sector  identification. 

7.  Check  for  altitude  data,  present  and  reasonable. 

a.  If  data  is  usable,  set  initial  vertical  position 
and  set  the  velocity  prediction  to  a  small  non-zero 
value.  Set  the  altitude  measurement  time  and 
initialize  FIRMZ  =  1. 

b.  If  data  is  not  usable,  set  FIRMZ  =  0. 

8.  Set  the  smooth/predict  flag.  Clear  the  ATARS  service 
and  drop  flags,  ATSS,  DRSUR,  DRATS  and  the  data  flags  LOFL, 
RMFL. 


9.  Set  the  controlled/uncontrolled  indicator  according  to 
the  new  report. 

10.  Clear  REMA,  REMD  if  this  surveillance  report  is  a 
duplicate. 

11.  Check  the  report  source. 

a.  If  the  report  source  is  ATCRBS,  set  the  track  type 
to  ATCRBS,  and  if  Mode  3/A  data  is  available  insert  it 
in  CODE. 

b.  If  the  report  source  is  DABS,  set  CODE  to  this  ID, 
set  TYPE  to  DABS  and  form  a  new  CREFD  link  to  this 
track. 

4.3  Track  Processing 

The  Track  Processing  Task  performs  the  final  elimination  of 
tracks  which  are  not  to  be  serviced  by  ATARS  and  track  update 
processing.  All  surveillance  reports  have  been  associated  with 
tracks  or  used  to  start  new  tracks  in  the  Report  Processing 
Task.  Track  processing  accepts  each  report  and  calls  the  Track 
Update  Routine  (Section  4.5.1).  All  report  correlation  is 
accomplished  in  the  DABS  sensor  and  is  accepted  as  being 
complete  by  ATARS. 

The  flow  chart  for  the  Track  Processing  Task  is  given  in  Figure 
4-6.  Input  data  for  track  processing  consists  of  local  or 
remote  reports  with  remote  times  of  measurement  which  have  been 
stored  with  the  associated  track  in  CTS  by  report  processing 
(one  report,  or  none,  per  track). 
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Track  processing  operates  once  each  time  the  local  sensor 
antenna  enters  a  new  sector  and  processes  tracks  in  particular 
sectors  (relative  to  the  antenna).  The  sectorization  of  CTS  is 
accomplished  by  threading,  which  is  updated  as  aircraft  positions 
are  repredicted. 

The  program  is  organized  so  that  when  the  antenna  enters  sector 
n,  all  tracks  in  sector  n-4  are  processed.  Then  all  tracks  in 
sector  n-20  are  processed,  (see  the  timing  diagram,  Figure  4-7). 
The  sector  gap  from  n  to  n-4  allows  time  for  DABS  sensor 
processing  and  transmission  delays.  The  maximum  delay  for 
surveillance  input  reports  is  expected  to  be  3  sectors  (3/8 
second) . 

The  primary  function  of  track  processing  is  to  perform  track 
updates  in  sector  n-4  normally  with  local  data,  but  if  this  is 
missing,  to  attempt  remote  data  updates  twice  per  scan  in  sectors 
n-4  and  n-20.  This  double  attempt  allows  timely  use  of  remote 
reports.  Also,  late  local  reports  are  processed  in  sector 
n-20.  Various  processing  flags  and  time  checks  are  utilized  to 
prevent  too  frequent  updates  or  confusion  because  of  sector 
changes. 

The  services  performed  are  as  follows: 

1.  Sector  n-4  -  First  Pass  Processing 

a.  Index  all  tracks  in  this  sector  whose  smooth/ 
predict  and  antenna  sector  process  flags  are  not  set. 

b.  If  a  report  is  not  a  null  report,  use  this  data  and 
perform  a  track  update  (hit).  This  includes  smoothing 
and  prediction. 

c.  If  a  null  report  has  been  stored,  perform  a  track 
update  (miss).  This  provides  prediction  only. 

d.  Set  the  antenna  sector  process  flag  in  the  state 
vector. 

2.  Sector  n-20  -  Second  Pass  Processing  (Remote  Reports) 

a.  Index  all  tracks  in  this  sector  and  late  local 
reports. 

b.  For  each  track  check  whether  remote  data  has  been 
stored  and  that  the  smooth/predict  flag  is  clear  and 
the  antenna  sector  process  flag  is  set.  If  this  is 
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true  accept  the  remote  data  and  perform  a  track  update 
(hit)  which  includes  smoothing  and  prediction.  Also 
perform  this  step  for  late  local  reports.  Otherwise, 
skip  this  step. 

c.  Clear  smooth/predict  and  antenna  sector  process 
flags . 

The  flags  used  in  this  logic  are  maintained  in  the  individual 
track  state  vectors  as: 

Remote  data  flag 
Local  data  flag 
Smooth/predict  flag 
Antenna  sector  process  flag 

4.5.1  Track  Update 

The  Track  Update  Routine  is  depicted  in  Figure  4-8.  This 
routine  has  two  points  of  entry.  One  is  used  to  process  a  track 
after  a  report  has  been  selected  (a  hit);  the  other  entry  is 
used  to  process  the  track  in  final  prediction  only  if  the  track 
report  is  a  null  (a  miss).  The  main  routine  uses  smoothing  and 
prediction  and  performs  other  state  vector  update  functions  as 
well.  Accessory  bookkeeping  operations  affect  the  CREFA  and 
CREFD  files. 

The  following  special  services  are  performed  for  a  hit. 

1.  Find  the  measurement  time  for  the  current  report.  If 
the  report  is  local,  this  time  is  computed  from  the  report 
azimuth  and  the  antenna  position/rate  estimates.  If  the 
report  is  remote,  the  rime  has  been  determined  by  the 
Report  Processing  Task  and  stored  as  TMR  (see  Section 
4.7).  The  time  of  the  current  report,  TM^^ ,  should  be 
set  equal  to  TMR.  DLOUT  (parameter  indicating  that  the 
lo-'al  sensor  lost  data  link  contact  with  the  aircraft  on 
the  most  recent  scan)  is  initially  set  for  every  pass 
through  this  routine.  It  is  only  reset  if  a  local  DABS 
report  is  used. 

2.  Correct  the  previous  predictions  for  this  track  to  the 
current  measurement  time,  if  necessary.  The  predictions 
are  for  an  anticipated  time  of  local  data  measurement. 

Thus,  if  this  report  is  local,  no  correction  will  ordinarily 
be  required.  However,  remote  data  will  be  measured  at  quite 
different  times,  and  the  previous  predictions  must  be 
corrected.  Correction  is  accomplished  by  shifting  the  X,  Y 


=  RMFL 
=  LOFL 
*  SMPR 
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FIGURE  44 

TRACK  UPDATE  ROUTINE  (Ptfl»  2  of  5) 


FIGURE  4-8 

TRACK  UPDATE  ROUTINE  (Page  4  ol  5) 


A!  S«re  PJ?'yARY/S-rr.r.sr»AKY 


FIGURE  M 

TRACK  UPDATE  ROUTINE  (Ptft  5  „ 


4- 


22 


and  2  predicted  coordinates  by  the  time  difference  (TMP  - 
TMR)  times  the  internal  X,  Y  and  Z  velocity  estimates. 

Both  internal  and  external  predictions  will  be  affected 
(see  Section  4.6 ) . 

3.  Coordinate  convert  rho,  theta  data  to  the  local  X,  Y 
system.  Conversion  of  local  data  involves  slant  range 
correction  as  indicated  in  Figure  4-1.  For  remote  reports 
a  full  remote  to  local  system  conversion  must  be  used. 

These  conversions  utilize  the  altitude  measurement  if 
present.  Otherwise,  the  estimated  altitude  is  used.  In 
cases  where  neither  is  available,  a  nominal  value  of  ZNOM 
will  be  assumed.  The  slant  range  for  both  local  and  remote 
surveillance  reports  must  be  transferred  into  SLREPS  before 
any  coordinate  conversions  are  made  to  the  data. 

4.  If  this  report  is  local,  set  the  smooth/predict  flag. 

If  the  report  is  a  DABS  report,  check  the  identity  of  the 
remote  site  in  the  CIR  using  REMCIR.  If  REMCIR  is  positive, 
send  a  message  to  this  ATARS  site  to  stop  sending  CIR  data 
to  this  aircraft  and  inform  the  local  DABS  sensor  to  start 
ATARS  service  for  this  aircraft.  If  REMCIR  is  negative, 
then  the  remote  site  identified  in  the  CIR  is  where  data 
may  be  requested.  Reset  the  DLOUT  flag  in  the  state  vector 
of  this  aircraft. 

5.  If  this  report  is  remote,  check  the  measurement  X,  Y 
position  against  the  external  prediction  (corrected)  for 
reasonableness.  If  not  reasonable,  return  without  an 
update.  If  the  cone  of  silence  flag  is  set  (COSFL) ,  the 
ATARS  service  flag  is  set  (ATSS),  the  aircraft  is  ATARS 
equipped  (ATSEQ),  and  REMCIR  is  negative  (remote  site 
identified  from  which  data  will  be  requested)  a  message  is 
sent  to  the  site  requesting  CIR  data  for  this  aircraft. 

Sent  along  with  this  message  is  own-site  ATARS  identifica¬ 
tion  and  the  state  of  remote  site  life  scan  flag  (OSCFL). 
Inform  the  local  DABS  sensor  to  stop  ATARS  service  for  this 
aircraft. 

6.  Perform  X,  Y  smoothing  with  the  ATARS  horizontal 
smoothing  algorithm. 

7.  If  altitude  data  is  present  with  this  report,  check  it 
for  reasonableness  (with  respect  to  altitude  limits  and 
prediction).  If  reasonable,  perform  Z  smoothing  with  the 
ATARS  vertical  smoothing  algorithm. 
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8.  Replace  the  old  X,  Y  measurement  time,  TM,  by  the  new 
report  time,  TM^EXT. 

9.  Set  the  controlled/uncontrolled  flag  according  to  the 
new  DABS  report. 

10.  Clear  the  local  and  remote  data  flags;  LOFL,  RMFL. 

The  following  special  services  are  perfoimed  for  a  miss. 

1.  Set  the  DLOUT  flag  in  the  state  vector  of  this 
aircraft.  The  flag  will  not  be  reset  for  a  miss. 

2.  If  present  time  minus  TM  is  greater  than  TDROP,  then 
set  the  drop  flag  (DRSUR),  place  aircraft  on  deletion  list 
and  unlink  from  X/  EX-list;  otherwise,  ignore. 

The  following  common  services  are  performed  for  either  a  hit  or 
miss  after  the  special  services  have  been  completed. 

1.  If  the  drop  flag,  DRSUR,  is  set,  test  the  ATARS  service 
flag,  ATSS.  If  this  is  not  set,  the  track  is  dropped  and 
its  cross-reference  links  (CREFA  or  CREFD)  are  erased.  If 
ATSS  is  set,  the  State  Vector  Deletion  Task  has  responsi¬ 
bility  for  the  drop;  however,  an  ATCRBS  track  cross- 
reference  (CREFA)  must  be  deleted  here. 

Dropping  a  track  here  consists  of  simply  rethreading  it 
onto  the  empty  list. 

2.  Predict  track  horizontal  and  vertical  positions  to  the 
estimated  time  of  next  local  data  for  this  track  using  the 
ATARS  prediction  algorithm.  Compute  the  predicted  rho, 
theta  and  store.  Store  the  prediction  time,  TMP. 

3.  Test  the  track  for  ATARS  qualification.  (NOTE: 

Firmness  control  is  discussed  in  Section  4.5.2).  Tracks 
are  qualified  for  ATARS  service  if  they  have: 

a.  FIRMI  .GE.  FESTAB 

b.  FIRMZ  , NE .  0 

c.  (clock  time  -  TMZ)  .LE.  TMZMAX 

If  the  track  is  not  qualified,  see  if  track  is  on  the  X, 

EX-list.  If  true,  set  the  drop  service  flag,  (DRATS),  place  the 
aircraft  on  the  deletion  list  and  unlink  from  X/  EX-list; 
otherwise,  ignore. 


If  the  track  is  qualified,  see  if  on  X,  EX-list.  If  not  in 
either  list  place  in  the  XINIT  list  for  the  Aircraft  Update 
Processing  Task  by  use  of  NEXTX.  If  track  is  on  X,  EX-]ist  and 
ATSS  is  not  already  set,  test  the  track  position  estimates 
(external  prediction;  XP,  YP,  ZP)  to  determine  whether  the  track 
lies  within  the  ATARS  service  area.  This  is  accomplished  by  a 
geographical  area  determination  which  utilizes  an  X,  Y  masking 
procedure.  This  X,  Y  mask  is  defined  as  the  ATARS  mask  service 
area  as  shown  in  Figure  4-4.  The  mask  is  divided  into  seam 
sectors  which  are  defined  by  rho,  theta  limitations. 

If  the  track  is  within  the  area,  set  the  ATSS  flag.  The  tracks 
are  placed  on  the  appropriate  X  or  EX-list  in  the  aircraft 
update  task.  If  the  aircraft  is  ATARS  equipped,  a  message  is 
sent  to  the  DABS  sensor  to  start  ATARS  service  for  this  track. 
For  all  DABS  tracks,  the  primary/  secondary  status  of  the  track 
is  recorded  in  the  state  vector  (PSTAT). 

4.5.2  Firmness  Control 

The  ATARS  tracking  system  uses  the  method  of  firmness  controlled 
smoothing  parameters  (see  Table  4-1).  Firmness  values  for  each 
track  are  adjusted  in  accordance  with  its  record  of  correlation 
success  (see  Table  4-2).  The  firmness  table  construction  and 
use  for  the  ATARS  tracking  system  differs  from  its  Augmented 
ARTS  III  counterpart  in  several  ways.  The  following  features 
are  present . 

1.  Fewer  levels  have  been  assigned  and  the  alpha,  beta 
smoothing  parameter  values  of  these  levels  have  been 
altered. 

2.  Together  with  alpha  and  beta  an  additional  threshold 
parameter,  THK,  has  been  added  to  adjust  ATARS  cross-track 
smoothing  thresholds.  (The  notation  (THK  =  ***)  means  that 
the  ATARS  turn  detection  should  be  disabled.) 

3.  Three  firmness  values,  FIRMI ,  FIRME  and  FIRMZ,  are 
maintained  on  each  track.  Each  uses  the  same  lookup  table 
to  select  parameters  for  internal  X,  Y,  for  external  X,  Y, 
or  for  altitude  smoothing.  FIRMI  is  used  for  THK  lookup. 

4.  These  firmness  values  step  up  or  down  depending  on  the 
success  or  failure  of  attempts  to  correlate  on  a  particular 
scan.  The  adjustments  are  made  after  the  previous  firmness 
levels  have  been  used  for  lookup.  Nominal  adjustments, 
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!  TABLE  4-1 

t 

'  SMOOTHING  PARAMETERS  VS.  FIRMNESS 


[ 

■  FIRM 

ALFA 

BETA 

THK 

|  0 

1.000 

0.000 

- 

I 

1.000 

1.000 

2 

1.000 

1.000 

★  ★★ 

3 

‘ 

.833 

.700 

3.60 

4 

.700 

.409 

2.00 

5 

.600 

.270 

1.50 

6 

.524 

.192 

1.26 

7 

.464 

.144 

1.12 

8 

.417 

.112 

1.03 

9 

.400 

.100 

1.00 

***  Indicates  a  very 

large  positive 

value  which 

disables 

turn  detection. 


* 
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TABLE  4-2 


FIRMNESS  TABLE  STEP  CONTROL 


FIRM  (CURRENT  VALUE) 
0 
1 
2 

3 

4 

5 

6 

7 

8 
9 


CORRELATION  SUCCESS 
FIRM  (NEXT  VALUE) 

2 

3 

3 

4 

5 

6 

7 

8 
9 
9 


CORRELATION  FAILURE 
FIRM  (NEXT  VALUE) 

0 

1 

2 

2 

2 

3 

4 

5 

6 
7 


Note:  Additional  maximum  limits  may  be  applied  to  firmness  levels. 
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which  are  common  to  all  three  firmness  values,  are  further 
subject  to  absolute  assigned  maximum  firmness  limits. 
Nominal ly , 


FIRMImax  =  9 

FIRM^ax  =  ^ 

FIRM^ax  =  7 

These  values  cannot  be  exceeded  during  stepping.  Note  that 
a  successful  rho,  theta  correlation  does  not  necessarily 
result  in  a  successful  altitude  correlation  so  that  FIRMZ 
does  not  necessarily  increase  with  FIRM I  and  FIRME.  Al¬ 
titude  reports  may  be  missing  or,  if  present,  they  must 
pass  a  reasonableness  test  before  they  are  accepted  for 
smoothing. 

5.  When  a  track  is  initiated,  FIRMI  and  FIRME  are  inserted 
at  level  1.  Similarly,  if  altitude  data  on  this  new  track 
has  been  received,  FIRMZ  is  also  initialized  at  1 .  If  no 
altitude  data  has  been  received,  set  FIRMZ  =  0. 

6.  A  track  is  terminated  when  the  time  interval  between 
the  current  time  and  the  time  of  the  last  successful 
horizontal  reply  (represented  by  TM)  exceeds  the  threshold 
value  TDROP. 

7.  All  turning  track  firmness  levels  used  in  ARTS  III  have 
been  deleted. 

4.6  Track  Estimation 


Track  estimation  consists  of  two  processes:  smoothing,  in  which 
a  track's  current  data  is  combined  with  a  previously  made  predic¬ 
tion  to  achieve  an  impi^ved  estimate  of  the  current  state,  and 
prediction,  in  which  the  current  smoothed  state  is  extrapolated 
one  scan  ahead  to  assist  correlation  and  prepare  for  the  next 
smoothing  step.  Figure  4-9  illustrates  turn  sensing,  smoothing 
and  prediction  based  on  the  current  positions  and  velocities. 

Smoothing  and  Prediction  Routines  are  called  in  the  main  Track 
Update  Routine.  The  essential  data  communicated  to  the 
smoothing  algorithm  is: 

a.  the  track  to  be  processed, 

b.  the  report  to  be  used  for  smoothing, 

c.  estimates  of  antenna  position  and  rate. 
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The  prediction  algorithm  requires  only  the  first  and  third 
items.  Both  algorithms  modify  the  contents  of  the  track  state 
vector.  In  both  smoothing  and  prediction,  reference  is  made  to 
internal  and  external  position  and  velocity  coordinates.  Inter¬ 
nal  refers  to  those  positions  and  velocities  used  internal  to 
the  Track  Processing  Task.  External  includes  all  positions  and 
velocities  used  elsewhere  in  the  ATARS  tasks  but  generated  in 
the  Track  Processing  Task. 

4.6.1  Smoothing 

The  ATARS  track  Smoothing  Routine  is  designed  to  provide 
vertical  velocity  information  and  improved  knowledge  of  aircraft 
heading  during  turns.  Thus,  ATARS  conflict  detection  and 
conflict  resolution  may  be  performed  more  effectively  for 
maneuvering  aircraft  than  has  been  possible  with  previous  ATC 
algorithms. 

Horizontal  (X,  Y)  positions  and  velocities  are  smoothed  by  the 
well-known  alpha,  beta  technique  until  a  maneuver  is  sensed. 

The  cross-track  deviation  (data  report  distance  from  the  line  of 
the  predicted  track  vector)  is  compared  with  an  assigned  thres¬ 
hold  to  detect  a  turn.  If  a  turn  is  detected,  the  turn  rate  (W) 
is  computed  from  a  modified  cross  track  deviation  computed  from 
the  oldest  of  three  previous  smoothed  positions  and  velocities. 
Figure  4-10  illustrates  turn  rate  computation  (in  relation  to 
Figure  4-9)  using  historical  positions  and  velocities.  Figure 
4-11  illustrate  the  turn  rate  computations  used  for  the  advisory 
service  in  ATARS.  Maneuvering  tracks  are  smoothed  by  a  special 
method  which  includes  track-oriented  geometric  calculations. 

The  following  implementation  avoids  use  of  trigonometric  func¬ 
tions  wherever  possible.  Vertical  (Z)  positions  and  velocities 
are  smoothed  by  an  alpha,  beta  filter  (without  modification 
during  maneuver). 

These  smoothing  operations  are  controlled  by  three  important  CTS 
track  firmness  parameters,  FIRMI,  FIRME,  and  FIRMZ,  which  are 
maintained  by  the  correlation  program  in  accord  with  the  record 
of  correlation  successes  and  failures.  Table  4-1  shows  how  the 
various  Smoothing  Routine  parameters  vary  with  these  firmness 
values  (denoted  generically  by  FIRM).  (The  level  zero  is 
restricted  to  FIRMZ  and  requires  only  alpha,  beta  parameters.) 
The  X,  Y  Smoothing  Routine  is  illustrated  in  Figure  4-12. 

Before  the  X,  Y  Smoothing  Routine  is  entered,  the  measured  range 
and  azimuth  are  converted  to  Cartesian  XR,  YR  components.  CTS 
contains  the  predicted  internal  position  XPI1,  YPI1,  and 
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FIGURE  4-10 

PREDICTION  AND  CROSS  TRACK  DEVIATION 
USING  HISTORICAL  POSITIONS  AND  VELOCITIES 


r 


SIN  A  -  b/r 

b  -  2r  SIN  A/2 
d  -  b  SIN  A/2 
-  2r  SIN2  A/ 2 

approx.  *  2r  A2/ A  FOR  SMALL  A 


A  -  wt  t  -  TIME  FOR  n  SCANS 


rA  *  vt  v  -  VELOCITY 


d  “  2(vt)wt/4 
M  1/2  vwt 2 

w  -  2d/vt2  TURN  RATE 

SUBSTITUTING  FOR  d  AND  v,  THE  TURN  RATE  EQUATION  IS: 
W  -  2CTDA/(XDIOLD2+YDIOLD2)  *  (DT+ST)2 

FIGURE  4-11 

TURN  RATE  COMPUTATION  FOR  ADVISORY  SERVICE 
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velocity,  XDI1,  YDIl ,  estimates  for  the  current  predicted  data 
time,  TMPl.  CTS  also  contains  up  to  three  previous  smoothed 
internal  positions,  velocities,  old  data  times,  and  the  special 
predicted  positions  used  for  the  turn  rate.  For  an  update  with 
local  data,  TMPl  is  sufficiently  close  to  the  true  measurement 
time  that  these  predictions  may  be  directly  compared  with  the 
measurements.  For  an  update  with  remote  data,  the  predictions 
XP11,  YPI1  are  first  corrected  to  the  remote  measurement  time  by 
using  the  velocities  XDI1,  YDIl  and  applying  the  time  difference 
TMRl-TMPl . 

Several  quantities  to  be  used  in  the  computation  of  the  turn 
rate  are  initialized  in  the  Track  Initialization  Routine,  and 
are  available  in  the  state  vector.  These  variables  are  updated 
in  the  X,  Y  Smoothing  and  Prediction  Routines.  These  parameters 
are  outlined  below. 

Last  predicted  internal  velocity: 

XDIOLD  -  XDI1 
YDIOLD  *  YDIl 

Last  predicted  internal  position: 

XPINEW  «  XPI1 
YPINEW  -  YPI1 

Time  on  the  stack: 

ST  -  0 

The  stack  time  is  initialized  in  the  Track  Initialization  Routine 
and  stored  in  CTS.  The  stack  time  is  computed  each  scan  in  the 
Track  Processing  Task. 

Then  define  the  internal  deviation  vector  DI  as: 


__  '  DIX  '  '  XR  -  XPI1  ' 

DI  -  '  '  -  '  ’and 

'  DIY  '  '  YR  -  YPI1  ’ 


_  '  CTDIX  '  '  XR  -  XPINEW  ' 

CTDI  -  '  '  -  '  ' 

'  CTDIY  '  '  YR  -  YPINEW  ' 


Let  the  elapsed  time  since  the  last  X,  Y  data  was  received  on 
this  track  be  DT.  This  time  difference  is  calculated  from  the 
last  data  time,  TM1 ,  stored  in  CTS  and  the  new  data  time.  Mew 
data  time  for  local  reports  is  determined  here  from  the  measured 
azimuth  and  the  antenna  motion  estimates.  For  remote  reports  it 
is  determined  in  report  processing  and  stored  with  the  report 
(TMR1). 

Then  ALFA,  BETA  are  selected  through  FIRMI,  and  the  smoothing 
equations  produce  the  intermediate  estimated  coordinates 
designated  XA,  YA,  XDA,  YDA  as  follows: 

XA  =  XPI1  +  ALFA  *  DIX 

YA  =  YPI1  +  ALFA  *  DIY 

XDA  =  XDI1  +  BETA  *  DIX/DT 

YDA  =  YDI1  +  BETA  *  DIY/DT 

The  next  step  is  to  sense  for  turns.  Let 

A  =  DIX  *  YDI1  -  DIY  *  XDI1 

CTDA  =  CTDIX  *  YDIOLD  -  CTDIY  *  XDIOLD 

S  *  Sign  (A) 

B  «  XDIl2  +  YDI12 

The  cross  track  distance,  D,  used  for  turn  sensing  is 

D  ■  A/SQRT(B) 

The  square  root  can  be  avoided  by  dealing  with  the  square  of 
this  distance,  D2. 


D2  -  A2/b 

Let  D2TH  be  a  threshold  by  which  D2  is  measured  to  sense  a 
turn.  Then,  if  D2  .GT.  D2TH  and  S  is  negative,  a  left  turn  is 
sensed.  If  D2  .GT.  D2TH  and  S  is  positive,  a  right  turn  is 
sensed. 

The  threshold  is  computed  as  a  function  of  track  range,  speed, 
orientation  and  the  data  source  used  for  this  update.  It  is 
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further  modified  by  the  factor  THK  which  depends  on  FIRMI.  The 
calculation  of  D2TH  is  accomplished  through  two  intermediate 
quantitites,  DTHA  and  DTHB: 

D2TH  -  THK  *  (DTHA  +  DTHB  *  (XA  *  XDA  +  YA  *  YDA)2/(V2A  *  R2A)) 
where 


R2A  -  XA2  +  YA2 
V2A  *  XDA2  +  YDA2 

Physically,  DTHA  is  the  square  of  the  threshold  which  is 
appropriate  for  testing  the  radial  deviations  of  a  track  moving 
tangentially  to  the  radar.  DTHA  *  DTHB  is  the  square  of  the 
threshold  appropriate  for  testing  tangential  deviations  of  a 
track  moving  radially.  The  factor  multiplying  DTHB  is  the 
square  of  the  cosine  of  the  angle  between  the  track  direction 
and  the  radius  vector  from  the  radar.  Since  the  predicted  range 
is  available  from  CTS,  it  may  also  be  used  with  sufficient 
accuracy  in  place  of  the  R2A  computation  above.  The  quantities, 
DTHA  and  DTHB,  are  determined  from  sensor  error  standard 
deviations  and  track  speed  by  the  empirical  formulas: 

DTHA  -  (3.1  *  STDA  +  1.35  *  SQRT  (V2A))2 

DTHB  =  (3.1  *  STDB  +  1.35  *  SQRT  (V2A))2  -  DTHA 

The  speed  estimate,  SQRT(V2A),  must  be  expressed  in  knots  for 
this  calculation  when  the  other  quantities  are  in  feet. 

The  sensor  error  parameters,  STDA  and  STDB,  are,  respectively, 
the  radial  and  tangential  data  error  standard  deviations  as 
specified  in  Reference  1.  A  typical  parameter  set  for  each  data 
source  is  listed  in  Table  4-3.  Tangential  parameters  generally 
depend  on  the  track-range,  SQRT(R2A).  Since  remote  data  is  not 
oriented  conveniently  in  the  local  sensor  system,  a  pessimistic, 
isotropic  assignment  is  made. 

When  a  turn  is  sensed,  a  correction  in  the  direction  of  the 
sensed  turn  is  made  in  the  heading  of  the  aircraft.  Let  DR  be 
the  vector 


DR 


'  DRX  '  '  XD11  *  DT  +  DIX  ' 

I  I  B  I  • 

'  DRY  '  '  YDI1  *  DT  ♦  DIY  ' 
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TABLE  4-3 


THRESHOLD  PARAMETERS  IN  FEET 


SOURCE 

STDA 

STDBl 

Local  DABS  Beacon 

150 

.002  *  SQRT  (R2A) 

Local  ATCRBS  Beacon 

180 

.002  *  SQRT  (R2A) 

Local  Radar 

215 

.004  *  SQRT  (R2A) 

Remote  Beacon 

500 

500 

1  The  range,  SQRT(R2A),  should  be  expressed  in  feet. 


and  VA  the  vector 


'  XDA  ' 


VA  9 


The  magnitude  of  this  correction  is  half  of  the  angle  between 
vectors  DR  and  VA,  except  when  this  angle  exceeds  some  threshold, 
TTH,  in  which  case  the  correction  is  limited  to  TTH/2.  (it  is 
assumed  that  the  parameter,  TTH  will  be  less  than  90°).  Let 
phi  be  the  angle  between  vectors  DR  and  VA  and  let  CT2  9 
cos2(TTH). 


Define 


DRX  *  XDA  +  DRY  *  YDA 


P  =  Sign(C) 


(DRX2  +  DRY2)  *  V2A 


Define 


CP  *  SQRT(CP2) 

Let  sin  (abs(phi)/2)  9  SPD2  and  cos  (abs(phi)/2)  9  CPD2.  Where 
abs  means  the  absolute  value  of  the  parameter. 

SPD2  9  SQRT  ((l-CP)/2) 

CPD2  9  SQRT  ((l+CP)/2) 

Let  delta  theta  be  the  absolute  value  of  the  heading  correction 
and  let  SDT  9  sin  (delta  theta)  and  CDT  9  cos  (delta  theta). 

Let  STD2  9  sin( TTH/2)  and  CTD2  9  cos(TTH/2).  Then, 


8DT  9  STD2 
CDT  9  CTD2 


if  P  *  CP2  .LE.  CT2 


SDT  =  SPD2 
CDT  =  CPD2 


otherwise 


The  new  estimated  internal  velocity  coordinates  are: 


XDI1next  =  ^  *  CDT  +  S  *  YDA  *  SDT 
YDIinext  a  YDA  *  CDT  -  S  *  XDA  *  SDT 


if  D2  .GT.  D2TH 


XDIlnext  =  XDA 
YDHnext  *  YDA 


if  D2  .LE.  D2TH 


When  a  turn  has  been  sensed  in  the  same  direction  on  two 
consecutive  updates,  an  additional  heading  correction  of 
magnitude,  DELTA,  is  applied  in  the  direction  of  turn.  Let  SDEL 
=  sin( DELTA)  and  CDEL  =  cos (DELTA). 

The  final  external  velocity  coordinates,  designated  XDE1  and 
YDE1,  used  as  a  source  of  the  coordinates  in  ATARS  detection  and 
resolution  are: 

XDElnext  *  XDIlnext  *  CDEL  +  S  *  YDIlnext  *  SDEL 
YDElnext  =  YDIlnext  *  CDEL  -  S  *  XDIlnext  *  SDEL 
if  a  turn  is  sensed  on  two  consecutive  updates,  or 

XDElnext  -  XDIlnext 

YDElnext  =  YDIlneXt 

otherwise. 

Note  that  the  DELTA  correction  affects  the  data  used  for  detec¬ 
tion  and  resolution,  but  does  not  influence  the  internal  tracker 
velocities,  and,  hence  is  not  propagated  into  the  future. 


4-40 


The  smoothed  internal  position  estimates  are: 


XSI1  =  XA 
YSI1  -  YA 

XSI1  and  YSI1  are  local  variables  and  are  processed  further  by 
prediction  which  occurs  later. 

The  horizontal  maneuver  status  indicator,  HMS1,  stores  the  turn 
indication  for  use  on  the  next  update.  It  is  set  to  zero  during 
track  prediction  if  the  predicted  time  of  the  miss  data  is  later 
than  THMS  beyond  the  last  data  time. 

Let  XP1,  YP1  be  the  external  estimates  used  in  ATARS.  These  are 
position  predictions  for  the  current  data  time,  but  distinct  and 
separate  from  the  internal  estimates.  Define  the  external 
deviation  vector  DE  as: 


__  '  DEX  '  '  XR  -  XP1  ' 

DE  =  1  '  *  '  ' 

'  DEY  '  '  YR  -  YP1  ' 


Here,  too,  for  remote  data  a  preliminary  correction  is  applied 
to  XP1,  YP1  using  XDI1,  YDI1  and  the  time  difference  TMR1-TMP1. 

After  ALFA  is  selected  through  FIRME,  the  smoothed  estimates 
XS1,  YS1  are  produced  by  the  operation: 

XS1  -  XP1  +  ALFA  *  DEX 

YS1  *  YP1  +  ALFA  *  DEY 

XS1  and  YS1  are  local  variables  and  are  processed  further  by 
prediction  which  occurs  later. 

Both  internal  and  external  position  estimates  are  propogated 
into  the  future,  but  positions  predicted  for  turn  rate  comput¬ 
ations  (see  Figure  4-11)  are  completely  independent  and  are  not 
propagated  into  the  future.  The  reason  for  these  two  types  of 
estimates  is  that  the  internal  positions  are  designed  to  provide 
effective  turn  sensing  while  the  external  estimates  provide  more 
accurate  actual  positions  for  ATARS  and  track  data  correlation. 
External  velocities  are  used  for  correction. 
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The  Detect  Task  and  Resolution  Evaluation  Routine  use  the  turn 
status  as  determined  by  the  following  logic.  The  turn  sensing 
algorithm  will  have  seven  states  (noted  in  Table  4-4)  represent 
ing  different  degrees  of  confidence  that  the  aircraft  is  actually 
turning.  The  cross  track  deviation  (D2)  will  be  checked  against 
two  thresholds  (TH1,  TH2)  which  are  computed  from  the  equations 
shown  on  Table  4-5.  One  threshold  will  be  small  enough  so  that 
the  probability  of  a  missed  alarm  is  small  and  there  is  little 
delay  in  detecting  a  turn.  The  other  threshold  will  be  large 
enough  so  that  the  probability  of  a  false  alarm  or  wrong  alarm 
is  minimized  (see  Reference  6).  The  transition  diagram  for  the 
turn  sensing  states  is  summarized  in  Table  4-6. 

Figure  4-13  shows  the  flow  chart  for  the  Z  Smoothing  Routine. 

The  vertical  portion  of  the  ATARS  tracker  is  the  more  customary 
alpha,  beta  tracker.  ALFA,  BETA  values  are  used  as  selected 
through  FIRMZl.  Let  the  reported  altitude  be  ZR.  At  the  time 
when  smoothing  occurs  the  altitude  estimate  slot  in  CTS  holds 
the  predicted  altitude  ZP1  for  the  current  data  time  of  a  local 
report.  For  remote  reports  the  prediction  is  first  corrected 
using  ZDE1  as  with  other  predictions  above.  The  smoothing 
relations  are: 

ZS1  =  ZP1  +  ALFA  *  (ZR  -  ZP1) 

ZDElnext  =  ZDE1  +  BETA  *  (ZR  -  ZP1)/DTZ 

where  DTZ  is  the  elapsed  time  since  the  last  altitude  data  was 
measured. 

DTZ  =  TM1 NEXT  “  TMZ 1 

Note  that  DTZ  is  not  necessarily  equal  to  DT.  It  is  calculated 
in  a  similar  way,  however,  using  the  last  time  of  altitude  data, 
TMZ1,  stored  in  the  state  vector.  ZS1  and  ZDElnext  are  local 
variables  and  are  processed  further  by  prediction  which  occurs 
later.  After  smoothing  set  TMZ1  *  TM^next* 

In  the  case  that  the  report  is  a  radar  fill-in  or  for  other 
reasons  the  altitude  measurement  is  not  usable, 

ZS1  -  ZP1 

ZDElneXt  =■  ZDE1 


TABLE  4-4 


TURN  SENSING  STATES 


TURN  1 
(STATE) 


-2 

We 

are 

-1 

We 

are 

0 

We 

are 

+  1 

We 

are 

+2 

We 

are 

-3 

We 

are 

+3 

We 

are 

DEFINITION 

very  confident  that  the  aircraft  is  turning  left, 
slightly  confident  that  the  aircraft  is  turning  left, 
very  confident  that  the  aircraft  is  going  straight, 
slightly  confident  that  the  aircraft  is  turning  right, 
very  confident  that  the  aircraft  is  turning  right, 
uncertain  about  the  aircraft's  turn  status, 
uncertain  about  the  aircraft's  turn  status. 
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TABLE  4-5 


EQUATIONS  FOR  TURN  SENSING 

(XA  *  XDA  +  YA  *  YDA)2 

C2T  = 

V2A  *  R2A 

CRNG1  *  (TRKW1  *  STDA  +  TRKW2  *  SQRT  (V2A))2 
CAZ1  -  (TRKW1  *  STDB  +  TRKW2  *  SQRT  (V2A))2  -  CRNG1 
TH1  *  THK  *  (CRNG1  +  CAZ1  *  C2T) 

CRNG2  =  (TRKSI  *  STDA  +  TRKS2  *  SQRT  (V2A))2 
CAZ2  -  (TRKSI  *  STDB  +  TRKS2  *  SQRT  (V2A))2  -  CRNG2 
TH2  -  THK  *  (CRNG2  +  CAZ2  *  CZT) 
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TABLE  4-6 


TRANSITION  DIAGRAM  FOR  TURN  SENSING 


STATE 

STRONG 

WEAK 

STRAIGHT 

WEAK 

STRONG 

(TURN) 

LEFT 

LEFT 

RIGHT 

RIGHT 

(IHIT— 2) 

(IHIT—1) 

(IHIT-0) 

(IHIT-+1) 

(IHIT«+2) 

-2 

-2 

-1 

0 

+3 

♦3 

-1 

-2 

-1 

0 

♦3 

+3 

0 

-1 

-1 

0 

+1 

+1 

+  1 

-3 

-3 

0 

+1 

+2 

+2 

-3 

-3 

0 

+1 

+2 

-3 

-1 

-1 

0 

+3 

+3 

+3 

-3 

-3 

0 

+1 

+1 
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4.6.2  Prediction 


When  ■  track  receivea  data,  prediction  ia  done  juat  after 
smoothing.  The  varioua  aaoothed  estimates  are  projected  ahead 
to  the  next  local  correlation  tiae  uaing  the  appropriate  aaoothed 
velocitiea.  The  velocitiea  are  not  aodified.  When  a  track 
receivea  no  data,  the  previoua  predictiona  are  treated  aa  if  they 
were  new  aaoothed  eatiaatea  and  are  predicted  again.  In  thia 
caae,  prediction  ia  accoapliahed  during  firat  paea  proceaaing  in 
the  tracking  aodule. 

Figure  4-14  ahowa  the  flow  chart  for  the  X,  Y,  Z  Prediction 
Routine. 

Let  DS  be  the  eatiaated  tiae  to  the  next  local  report.  Then, 

mi1  *  XDUnext 

YDI1  -  YDIlnext 

XPI1  -  XSI1  +  DS  *  XDI1 
YPI1  -  YSI1  ♦  DS  *  YDI1 

XP1  *  XS1  +  DS  *  XDI1 
YP1  -  YS1  ♦  DS  *  YDll 

To  coapute  XPINEW,  YPINEW,  uae  tiae  at  atack  top  ainua  tiae  at 
atack  bottom  to  coapute  tiae  on  the  atack  (ST).  Dae  poaition 
and  velocity  on  the  bottom  of  the  atack,  ST,  and  DS  to  predict 
the  next  poaiton. 

Note  that  external  X,  Y  position*  ere  predicted  using  internal 
velocities.  This  is  done  to  reduce  the  possible  perturbations 
caused  by  false  turn  detections. 

The  vertical  prediction  is  accoapliahed  by  computing  the 
following: 

ZDE1  -  ZDElnext 

ZP1  -  ZS1  ♦  DS  *  ZDE1 

In  order  to  prepare  for  the  next  correlation,  the  predicted 
range  (RHOPl)  and  axiauth  (AZPl)  are  calculated  froa  the 
external  predictions  and  stored  in  the  track  file. 
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RHOPlnext  a  SQRT  <xpl2  ♦  Ypl2  ♦  ZP12) 

AZPlnext  *  tan  (XP1/YP1)  (with  quadrant 
determination) 

For  an  update  with  local  data,  DS  is  nominally  the  estimated 
scan  time  of  the  antenna. 

DSscan  «  .360° 

ARATE 

The  tangential  motion  of  a  track  near  the  antenna  may  require  a 
correction  of  this  value.  A  method  for  determining  whether 
correction  is  needed,  is  to  find  (AZPlnex^  -  AZP1)  and  then 
the  increment  of  extra  scan  time  which  this  predicted  azimuth 
change  requires.  The  extra  time,  DDS,  is  a  correction  of 
DSscan  and  may  be  positive  or  negative.  If  the  magnitude  of 
DDS  is  TDDS  or  greater,  the  predictions  are  recalculated  with 
the  exact  DS,  i.e., 

DS  *  DS8can  +  DDS 

For  an  update  with  remote  data, 


DS  -  TMP1  -  TMR1  + 


DSScan  +  °DS  Pass  1 
0  Pass  2 


The  time  for  which  the  predictions  are  made,  TMPlnexC,  is 
calculated  and  stored  in  the  state  vector. 

For  a  hit: 

THPlnext  ”  TMP1  ♦  DS 
For  a  miss: 

™P1next  ’  TMPl  ♦  DS 


(TM1  is  the  time  of  measurement  of  the  current  report,  which 
replaced  the  old  time  after  the  call  to  the  Z  Smoothing  Routine 
in  Figure  4-8.) 


4.7  Supporting  Routines 


This  section  provides  a  list  of  some  common  routines  required  by 
the  ATARS  tracker.  Particular  algorithms  are  outlined  in 
selected  cases.  Track  processing  control  flags  are  briefly 
summarized  and  their  utility  noted. 

Required  routines  of  particular  importance  are  the  following: 

1.  Antenna  Azimuth  Position/Rate  Estimation 

This  routine  is  called  by  the  Report  Processing  Task.  The 
input  consists  of  an  antenna  azimuth  position  from  the 
header  word  supplied  with  each  sector's  reports  in  the 
surveillance  buffer.  An  azimuth  is  received  each  sector, 
whether  or  not  there  are  accompanying  target  reports. 

It  is  also  necessary  to  read  the  ATARS  real-time  clock  at 
the  time  the  azimuth  is  extracted. 

The  antenna  estimate  is  embodied  and  stored  in  three 
variables  APOS,  ATIME,  ARATE.  Let  the  new  input  azimuth  be 
ANAZ  and  the  clock  time  CTIME.  Then  the  estimate  update  is: 

ARATEnext  *  O  "  ABETA)  *  ARATE  «•  ABETA  *  (ANAZ  -  APOS) 

(CTIME  -  ATIME) 

AP°snext  *  ANAZ 
ATIMEnext  -  CTIME 

ABETA  is  a  smoothing  constant  (approx.  “  .5).  If  ANAZ  - 
APOS  is  negative,  add  360°.  Thus  this  difference  is 
always  taken  as  a  positive  angle.  Check  CTIME  -  ATIME.  If 
too  small  (i.e.,  corresponds  to  less  than  1/2  sector)  skip 
the  update  for  this  antenna  sector. 

2.  Local  Report  Time  of  Measurement 

The  routine  is  used  wherever  local  reports  are  utilized  for 
track  update  or  initialization.  The  input  data  are  the 
measured  report  azimuth,  AZR,  and  the  antenna  estimates. 

The  algorithm  for  measurement  time,  TMnext  is: 

™next  "  ATIME  ♦  (AZR  -  APOS) 

ARATE 
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3.  Remote  Report  Time  of  Measurement 

This  operation  is  trival  and  is  included  only  for  contrast 
with  the  item  above.  Remote  report  time,  TMR,  is  computed 
during  report  processing  by  comparing  ATARS  clock  time  with 
the  report  storage  delay,  TDELA,  provided  with  the  report. 

TMR  =  TCLOCK  -  TDELA 

4.  Coordinate  Conversions 

a.  Local  rho,  theta  to  X,  Y. 

b.  Local  X,  Y  to  rho,  theta. 

c.  Remote  rho,  theta  to  local  X,  Y. 

See  Section  4.2  and  Figure  4-1  for  a  brief  general 
description  of  the  coordinate  framework. 

Note  that  remote  sensor  site  parameters  must  be  stored  and 
used  in  c  in  the  above  list.  A  selection  of  parameters  is 
made  through  the  sensor  ID  supplied  with  each  report. 

5.  Sector  Thread  Update 

The  requirements  of  this  program  (or  programs)  are  to: 

a.  add  a  new  track  to  a  sector  thread, 

b.  delete  a  track  from  a  sector  thread, 

c.  change  a  track  from  one  sector  thread  to  another. 

6.  DABS  Cross-Reference  (CREFD)  Update 

The  requirements  of  this  routine  are  to  create  or  delete  a 
CREFD  link  to  a  track. 

7.  CREFA  Reference 

This  routine  locates  a  given  track  in  CTS  from  its  ATCRBS 
file  number  by  utilizing  CREFA.  Or  it  determines  that  no 
reference  exists. 

8.  CREFD  Reference 

This  routine  provides  a  function  similar  to  7.,  but  for  a 
DABS  ID  using  CREFD. 


The  following  is  a  brief  sunmary  of  required  CTS  state  vector 
processing  flags  and  indicators  used  in  the  Track  and  Report 
Processing  Tasks.  Their  operation  and  function  in  the  program 
are  outlined. 

1.  LOFL:  local  data  flag 
RMFL:  remote  data  flag 

These  flags  indicate  the  source  type  of  a  report  stored 
with  a  track  in  CTS.  They  are  set  when  the  report  is 
stored  and  cleared  during  track  update  or  initialization. 

LOFL  and  RMFL  are  both  used  to  indicate  presence  or  absence 
of  data  from  a  particular  site. 

2.  SMPR:  smooth/predict  flag 

SPRO:  antenna  sector  process  flag 

These  flags  provide  internal  communication  and  prevent 
confusion  in  the  timing  of  operations  of  the  tracker. 

SMPR  is  set  when  local  reports  are  used  for  Track  Update  or 
Track  Initialization  Routine.  The  flag  is  cleared  in  second 
pass  remote  processing  in  the  Track  Processing  Task.  Its 
function  is  to  inform  later  program  tasks  that  an  update 
has  already  occurred  on  this  scan  and  to  defer  further 
updates  to  the  next  scan. 

SPRO  is  set  after  conclusion  of  first  pass  processing  in 
the  Track  Processing  Task.  It  is  cleared  after  second  pass 
(remote)  processing.  It  is  tested  before  each  track  is 
accessed  in  the  Track  Processing  Task.  It  inhibits 
reprocessing  a  track  in  the  second  pass  processing. 

3.  DRSUR:  drop  surveillance  flag 
DRATS:  drop  ATARS  service  flag 

These  flags  indicate  drop  conditions.  Both  exist  for  the 
benefit  of  the  State  Vector  Deletion  Task,  which  takes 
final  action  when  a  track  is  to  be  dropped. 

DRSUR  is  set  by  the  tracker  when  it  determines  that  a  track 
should  be  dropped  (drop  bit  received  or  too  much  time 
elapsed  since  last  data  input). 


DRATS  is  set  when  the  Track  Update  Routine  determines  that 
the  track  is  not  qualified  for  ATARS  service  or  is  outside 
the  service  area.  Otherwise,  it  is  cleared  during  update. 


4.  ATSS:  ATARS  service  flag 


This  flag  is  set  by  the  Track  Update  Routine  when  it 
determines  that  a  track  has  become  eligible  for  ATARS 
service.  It  inhibits  all  but  the  first  addition  of  a  track 
to  the  XINIT  list.  The  flag  is  cleared  by  the  State  Vector 
Deletion  Task  when  the  ATARS  service  is  discontinued  (in 
response  to  a  DRATS  indication  or  because  the  geography 
checks  shows  the  tracks  to  be  outside  the  service  area). 

Three  operations  require  coordinated  actions  between  the  Track 
Processing  Task  and  subsequent  ATARS  tasks.  These  are  to: 

1.  start  ATARS  service  for  a  track, 

2.  drop  ATARS  service  for  a  track, 

3.  drop  surveillance  for  a  track. 

A  surveillance  drop  is  a  total  drop  from  the  track  and  cross- 
reference  files.  But,  an  ATARS  service  drop  only  terminates 
this  service;  tracking  is  continued  to  be  used  by  the  Domino 
Routine. 

These  operations  are  coordinated  by  the  state  vector  flags; 

ATSS,  DRATS,  DRSUR.  Table  4-7  shows  in  each  case  the  actions 
initiated  by  track  processing  and  then  the  actions  taken  by  New 
Aircraft  Processing  or  State  Vector  Deletion  Tasks  to  complete 
the  operation. 

It  should  be  noted  that  ATARS  service  is  discontinued  when  a 
track  leaves  the  ATARS  service  area.  This  event  is  determined 
by  Geographical  Processing  Routine.  This  routine  sets  the  DRATS 
flag  directly  and  proceeds  with  the  final  actions  as  indicated 
in  the  table. 
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TABLE  4-7 


STEPS  REQUIRED  TO  START/DROP  ATARS  SERVICE  OR  DROP  SURVEILLANCE 


FUNCTION 


STEP  I 


STEP  II 


1.  Start  ATARS 
service 


TRACK  PROCESSING  TASK 
Set  ATSS  flag. 

Put  track  in  XINIT  list. 
Reset  DRATS. 


NEW  AIRCRAFT  PROCESSING  TASK 
Remove  from  XINIT  list. 

Put  in  appropriate  X 
list.  Set  INXFL . 

Initialize  State  Vector. 


2 .  Drop  ATARS 
service 


TRACK  PROCESSING  TASK 
Set  DRATS  flag. 

Reset  ATSS. 


3.  Drop  ATARS/ 
domino 
surveillance 


TRACK  PROCESSING  TASK 
Set  DRSUR  flag 
OR 

REPORT  PROCESSING  TASK 
Set  DRSUR  flag 
OR 

GEOGRAPHICAL  PROCESSING 

ROUTINE 

Reset  ATSS 

Set  DRATS 


STATE  VECTOR  DELETION  TASK 
Remove  track  from 
appropriate  X  list. 

Remove  from  sector  list 
and  add  to  empties* 

Erase  CREFD  link. 


*  This  action  effectively  erases  the  track  from  CTS. 
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NON-SURVEILLANCE  PROCESSING 


All  of  the  non-surveillance  data  passed  between  ATARS  and  the 
DABS  sensor  is  also  processed  on  an  antenna  sector  basis.  Some 
of  this  data  is  passed  through  the  Non-surveillance  Buffer.  The 
formats  of  these  messages,  which  apply  only  to  DABS  aircraft, 
are  presented  in  Table  5-1.  Certain  messages  are  processed  once 
per  sector  at  the  initiation  of  report  processing.  Other  mes¬ 
sages  are  processed  by  later  routines,  as  described  below.  The 
rest  of  the  data  is  passed  through  the  CIR  Buffer  and  reflects 
the  CIR  contents  for  each  DABS  aircraft. 

5.1  Incoming  Messages 

5.1.1  Uplink  Delivery  Notice  Processing 

ATARS  uplink  messages  for  an  individual  DABS  aircraft  are 
delivered  to  the  Uplink  Message  Buffer  as  an  ordered  set.  The 
UPMES  pointer  in  the  aircraft  state  vector  contains  the  location 
in  memory  of  this  set  of  messages  (UPLST).  The  position  of  each 
message  within  the  set  corresponds  to  its  intended  position  in 
the  desired  uplink  sequence.  The  ACMES  pointer  contains  the 
location  in  memory  of  the  set  of  messages  (ACLST)  which  was 
successfully  delivered  on  the  previous  scan.  The  DABS  sensor 
returns  an  uplink  delivery  notice  for  each  message  indicating 
its  success  or  failure  in  delivery.  All  notices  for  an  aircraft 
are  delivered  in  one  contiguous  block,  but  not  necessarily  in 
the  order  of  uplink.  For  this  reason,  delivery  notices  are 
numbered  to  correspond  to  the  intended  order  of  uplink. 

When  the  set  of  uplink  delivery  notices  for  each  aircraft  is 
processed,  the  message  number  field  in  each  notice  is  matched 
with  a  message  in  the  set  identified  by  UPMES.  Figure  5-1 
presents  these  two  data  structures.  Figure  5-2  presents  the 
flow  chart  for  processing  delivery  notices.  The  new  ACLST  is 
built  only  using  messages  which  were  successfully  delivered.  A 
local  flag  (ALLUP)  is  used  to  indicate  whether  all  uplinks  were 
successful.  If  so,  the  UPMES  pointer  is  set  equal  to  ACMES  and 
the  (duplicate)  UPLST  space  can  be  immediately  released.  Other¬ 
wise,  both  UPLST  and  ACLST  are  saved  so  that  other  tasks  may 
test  the  success  of  individual  messages  by  comparing  these  lists 

5.1.2  Data  Link  Capability  Message 

When  a  Data  Link  Capability  Message  is  received,  the  value  of 
ATSEQ  in  the  state  vector  is  set  to  indicate  whether  or  not  the 
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TABLE  5-1 


CONTENT  OF  MESSAGES  IN 


SENSOR-TO-ATARS : 

Uplink  Delivery  Notice 

Type  code 
DABS  ID 
Message  no. 

Successful  delivery  flag 

Data  Link  Capability 

Type  code 
DABS  ID 

Capability  field  value 

Sensor  Failure/Recovery 

Type  Code 
Site  ID 
Sensor  Status 


SURVEILLANCE  BUFFER 


AT ARS-TO- SENSOR: 

Start /Stop  ATARS  Service 

Type  Code 
DABS  ID 

ATARS  Site  ID  (local  or  remote) 
Start/Stop  flag 


BCAS  S quit  ter  Lockout 

Type  code 
DABS  ID 

Start/Stop  flag 


Set  BCAS  PLC 

Type  Code 
DABS  TD 
PLC  field 


Data  Link  Capability  Request 

Type  Code 
DABS  ID 
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aircraft  is  equipped  with  ATARS  or  BCAS.  If  the  aircraft  is  not 
equipped  with  ATARS,  it  will  be  considered  unequipped  and 
receive  no  direct  ATARS  service. 


The  detailed  flow  chart  of  the  Data  Link  Capability  Message 
Processing  Routine  is  presented  in  Figure  5-3. 

5.1.3  Sensor  Failure/Recovery 

The  ATARS  function  will  be  informed  of  the  failure  of  an 
adjacent  site  by  the  Sensor  Failure/Recovery  Message.  The  ATARS 
function  will  use  the  Site  ID  Field  to  initiate  the  failure  inode 
operation  logic  (see  Section  15). 

5.2  Outgoing  Messages 

5.2.1  Start/Stop  ATARS  Service 

When  an  aircraft  has  entered  the  ATARS  service  area,  a  start 
ATARS  service  message  will  be  sent  to  the  DABS  sensor.  The 
sensor  will  then  begin  to  uplink  the  ATARS  site  ID  each  scan  and 
downlink  the  CIR  rows  for  the  indicated  DABS  aircraft.  The 
start  message  is  generated  in  the  Track  Update  Routine.  A  stop 
ATARS  service  message  is  sent  to  the  sensor  when  the  aircraft 
leaves  the  ATARS  service  area,  or  when  the  track  is  lost.  This 
message  is  generated  in  the  Geographical  Processing  Routine  or 
in  the  Track  Update  Routine,  for  the  case  of  a  lost  track. 

5.2.2  BCAS  Squitter  Lockout 

When  an  aircraft  which  is  BCAS  equipped  penetrates  the  ATARS 
service  area  beyond  a  designated  ATARS-BCAS  seam,  the  BCAS 
Squitter  Lockout  Message  is  sent  to  the  DABS  sensor.  The  sensor 
surveillance  uplink  will  then  inhibit  BCAS  interrogations  while 
the  aircraft  is  inside  this  ATARS-only  area.  When  an  aircraft 
leaves  this  area,  an  end  message  is  sent  to  the  DABS  sensor. 
These  messages  are  implemented  in  the  Geographical  Processing 
Routine  (Section  6.3). 

5.2.3  Set  BCAS  Performance  Level  Control  (PLC) 


When  a  BCAS  aircraft  enters  the  ATARS  service  area,  ATARS  will 
generate  a  message  to  select  desensitized  BCAS  logic 
thresholds.  ATARS  uses  a  site-specific  area  map  to  determine 
the  applicable  zone  boundaries.  This  function  is  controlled  by 
the  Geographical  Processing  Routine.  Its  purpose  is  to  allow 
ATARS  to  be  the  primary  collision  avoidance  system  in  the  ATARS 
service  area. 
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5.3  Conflict  Indicator  Register  Processing 

The  Conflict  Indicator  Register  (CIR)  Processing  Task  is 
performed  after  CIR  rows  and  uplink  messages  from  the  local  site 
have  been  exchanged  with  a  CIR-equipped  aircraft.  The  purpose 
of  this  task  is  to  update  the  ATARS  conflict  data  and  to 
determine  the  acceptance  of  the  resolution  advisories  and 
handoff  messages  uplinked  by  the  local  site.  In  addition,  for 
conflicts  involving  a  controlled  aircraft,  the  Controller  Alert 
List  is  updated.  CIR  data  is  passed  from  DABS  to  ATARS  in  the 
CIR  Buffer.  Table  5-2  indicates  the  contents  of  the  CIR  Buffer. 

Figure  5-4  gives  the  flow  chart  for  the  CIR  Processing  Task.  In 
the  event  that  all  CIR  rows  and  uplinked  resolution  advisories 
are  not  successfully  exchanged  with  an  aircraft  during  the 
antenna  beam  dwell,  no  CIR  processing  takes  place  for  the 
aircraft  on  that  scan  except  for  the  processing  of  the  site  ID 
bits,  if  they  were  successfully  received. 

The  downlinked  CIRs  for  the  current  sector  are  processed  one  at 
a  time.  The  first  step  in  this  processing  is  to  send  the  con¬ 
tents  of  the  CIR  to  any  remote  ATARS  site  which  has  requested 
this  data.  This  is  done  in  the  CIR  Remote  Processing  Routine, 
which  is  shown  in  Figure  5-5.  When  this  requirement  is  dropped, 
the  Stop  Remote  CIR  Data  Routine,  described  in  Section  12.3,  is 
called. 

The  CIR  Processing  Task  next  tests  to  see  if  the  local  site  is 
providing  ATARS  service,  or  extended  service,  to  the  subject 
aircraft.  Extended  service  implies  that  the  aircraft  has  flown 
out  of  the  regular  service  area,  but  that  CIR  communications 
will  continue  until  all  required  handoff  messages  have  been 
successfully  uplinked  by  the  local  site.  This  condition  is 
indicated  when  the  DRATS1  flag  is  set.  If  service  is  being 
provided  by  the  local  site,  the  CIR  site  ID  bits  are  saved  in 
the  GE0G1  variable  and  processing  continues. 

The  CIR  Threat  Correlation  Routine  is  executed  next.  This 
routine  identifies  each  threat  indicated  in  a  CIR  row  and 
replaces  the  threat  ID  (and  ATCRBS  track  block)  with  a  pointer 
to  an  ATARS  state  vector  or  remote  list  entry.  The  CIR  Threat 
Correlation  Routine  is  described  more  fully  in  Section  5.3.1. 

Next,  a  series  of  routines  are  executed  to  update  the  ATARS 
conflict  data  for  the  subject  aircraft.  This  job  is  broken  up 
according  to  system  responsibility  for  each  conflict.  "Internal" 
conflict  pairs  are  defined  to  be  those  pairs  for  which  the  local 


TABLE  5-2 


CONTENTS  OF  THE  CIR  BUFFER 


The  CIR  Buffer  will  contain  the  following  data  for  each 
CIR-equipped  aircraft  in  the  current  sector  for  which  a 
successful  downlink  of  the  CIR  was  achieved: 

1.  Header,  consisting  of: 

Site  ID  Bits  -  A  4-bit  field  indicating  which  ATARS 

sites  are  currently  providing  service  to 
the  subject  aircraft. 

ACID  -  DABS  ID  of  the  subject  aircraft. 

2.  CIR  Rows  (variable  number;  or  null  if  none)  which  may  be  of 
two  different  types: 

(A)  Maneuver  Intent  Row,  consisting  of: 

TYPE  -  Threat  type  (DABS  or  ATCRBS) . 

D  -  Resolution  advisory  field.* 

VSL  -  Vertical  speed  limit  field,* 

considered  to  be  part  of  the  resolution 
advisory. 

RRS  -  Resolution  responsibility  field,* 

indicating  BCAS  responsibility 
(B-bit  set),  ATARS  responsibility 
(C-bit  set,  plus  row  ID),  or 
a  handoff  condition. 

TRTID  -  ID  of  threat  aircraft: 

If  TYPE  =  DABS,  TRTID  «  DABS  ID. 

If  TYPE  -  ATCRBS,  TRTID  consists  of: 

AIA  -  ATCRBS  ID  availability  flag. 

AID  -  ATCRBS  ID  code  (  =0  when  AIA 
is  not  set). 


*  Coding  of  these  fields  is  described  in  Reference  5. 
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TABLE  5-2 


CONTENTS  OF  THE  CIR  BUFFER 
(Concluded) 


(B)  ATCRBS  Track  Block  Row*,  consisting  of: 


R 

-  Range  of  threat. 

RD 

-  Range  rate  of  threat. 

THETA 

-  Bearing  of  threat. 

THDOT 

-  Bearing  rate  of  threat. 

Z 

-  Mode-C  altitude  of  threat. 

ZD 

-  Altitude  rate  of  threat. 

3.  Uplink  delivery  notices,  used  to  determine  whether  all 

resolution  advisories  were  successfully  delivered  by  the 
local  site. 


*  An  ATCRBS  track  block  row  immediately  follows  a  maneuver  intent 
row  where  TYPE  -  ATCRBS. 
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ATARS  site  has  chosen,  or  will  choose,  resolution  advisories. 
These  are  identified  by  pair  records  with  POSCMD  less  than  zero 
or  a  SEND  flag  (SEND1  or  SEND2)  which  is  set.  All  other  pairs 
are  "external"  pairs,  and  they  include  conflicts  where 
resolution  responsibility  belongs  to  BCAS  or  another  ATARS  site. 

The  External  Pair  Deletion  Routine  is  executed  first.  This 
routine  searches  the  existing  pair  records  to  determine  if  any 
external  CIR  rows  have  been  deleted.  The  routine  is  more  fully 
described  in  Section  5.3.2.  Next  is  executed  the  External  Pair 
Updating  Routine,  which  updates  the  ATARS  conflict  data  for  new 
and  existing  external  pairs.  This  routine  is  described  in 
detail  in  Section  5.3.3.  Finally,  the  Internal  Pair  Updating 
Routine  is  called  to  determine  the  compat ibi lity  of  uplinked 
resolution  advisories  with  existing  CIR  rows.  The  acceptance  of 
null  resolution  advisories  and  handoff  messages  is  also  noted 
and  recorded.  The  Internal  Pair  Updating  Routine  is  described 
in  Section  5.3.4. 

The  last  step  in  the  CIR  Processing  Task  is  to  update  the 
Controller  Alert  List  for  the  subject  aircraft  to  reflect  the 
resolution  advisories  actually  in  effect.  This  information  is 
extracted  from  the  updated  pair  records  involving  the  subject 
aircraft.  Note  that  the  controller  is  informed  of  each 
resolution  advisory  generated  by  the  local  site  only  after  it 
has  been  accepted  by  the  aircraft.  The  Update  Controller  Alert 
List  Routine  is  fully  described  in  Section  11. 

5.3.1  CIR  Threat  Correlation 


The  CIR  Threat  Correlation  Routine  is  flow  charted  in  Figure 
5-6.  Its  purpose  is  to  identify  each  threat  by  associating  it 
with  an  ATARS  state  vector  or  remote  list  entry.  Correlation 
takes  place  for  one  CIR  row  at  a  time. 

For  each  DABS  threat,  the  DABS  ID  code  is  used  to  determine 
whether  an  ATARS  state  vector  or  remote  list  entry  currently 
exists  for  the  threat.  If  not,  a  new  REMD  entry  is  created. 

The  DABS  ID  in  the  CIR  row  is  then  replaced  with  a  pointer  to 
the  state  vector  or  remote  list  entry. 

For  each  ATCRBS  threat,  the  CIR  ATCRBS  Correlation  Routine  is 
first  executed.  This  routine,  shown  in  Figure  5-7,  attempts  to 
correlate  the  threat  with  an  existing  state  vector  or  REMA  entry. 
It  is  intended  that  the  positional  correlation  logic  in  this 
routine  will  match  the  corresponding  avionics  logic,  described 
in  the  BCAS  collision  avoidance  algorithms  (see  Reference  5),  as 
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ENTER  WITH  CIR 
MANEUVER  INTENT 
AND  TRACK  BLOCK 
ROWS  FOR  ATCRBS 
THREAT 


Y 


A 


XL  •  XS  -  R  -  XCORR 

XU  «  XS  *  R  ♦  XCORR 

YL  -  YS  -  R  -  XCORR 

YU  •  YS  •  R  ♦  XCORR 

ZL  -  Z  -  2CORR 
Zll  ■  2  ♦  ZCORR 


GAMMA  »  ARCTAN(YDS/XDS)  -  THETA 
XT  -  XS  ♦  R*COS (GAMMA) 

YT  -  YS  ♦  R*SIN(GAMMA) 

XL  -  XT  -  XCORR 
XU  -  XT  ♦  XCORR 
YL  ■  YT  -  XCORR 
YU  -  YT  ♦  XCORR 
2L  -  Z  -  ZCORR 
ZU  -  Z  ♦  ZCORR 


DEFINITIONS: 

R  -  RELATIVE  RANCE  OF  THREAT 

THETA  -  RELATIVE  BEARING  OP  THREAT 

XC  -  X-COORDINATE  OF  CANDIDATE 

XS  -  X-COORDINATE  OF  SUBJECT 

YC  -  Y -COORDINATE  OP  CANDIDATE 

YS  -  Y -COORD IN ATE  OP  SUBJECT 

Z  •  ALTITUDE  OF  THREAT 

ZC  -  ALTITUDE  OP  CANDIDATE 


BECIN  COARSE 

CORRELATION 

SCREEN 


figure  »-r 

CIR  ATCRBS  CORRELATION  ROUTINE  t  Ot  8) 
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DEFINITIONS: 


R 

RC 

RD 

RDC 

THDOT 

THDOTC 

THETA 

THETAC 

XDC 

XDS 

YOC 

YDS 

Z 

zc 

ZD 

ZDC 


RELATIVE  RANGE  OF  THREAT 
RELATIVE  RANGE  OF  CANDIDATE 
RANGE  RATE  OF  THREAT 
RANGE  RATE  OP  CANDIDATE 
BEARING  RATE  OF  THREAT 
BEARINC  RATE  OF  CANDIDATE 
RELATIVE  BEARING  OF  THREAT 
RELATIVE  BEARING  OF  CANDIDATE 
X-VELOCITY  COMP.  OF  CANDIDATE 
X -VELOCITY  COMP.  OF  SUBJECT 
Y-VELOCITY  COMP.  OF  CANDIDATE 
Y- VELOCITY  COMP.  OF  SUBJECT 
ALTITUDE  OF  THREAT 
ALTITUDE  OF  CANDIDATE 
ALTITUDE  RATE  OF  THREAT 
ALTITUDE  RATE  OF  CANDIDATE 


FIGURE  5-7 

CIR  ATCR08  CORRELATION  ROUTINE  {P»0O  3  of  6) 
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FIGURE  8-7 
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FIGURE  5-7 

CIR  ATCRM  CORRELATION  ROUTINE  (Pag*  •  of  6) 
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closely  as  possible.  An  attempt  is  first  made  to  correlate  the 
threat  with  an  existing  state  vector  by  matching  the  ATCRBS  ID 
code  (if  available).  A  matching  non-1200  code  is  considered  an 
immediate  correlation  success.  If  the  ID  code  check  is 
inconclusive,  a  coarse  correlation  screen  of  positional  data  is 
performed  using  the  current  X-list.  The  result  is  a  list  of 
eligible  candidates  to  be  used  for  final  positional  correlation. 
One  candidate  is  chosen  from  the  list  whose  current  positional 
data  best  matches  that  in  the  ATCRBS  track  block  in  the  least- 
squares  sense. 

If  the  list  of  eligible  candidates  from  the  coarse  positional 
correlation  proves  to  be  empty,  an  attempt  is  next  made  to  match 
the  threat  with  existing  REMA  entries  for  any  threats  for  which 
a  pair  record  already  exists.  Again,  an  attempt  is  first  made 
to  march  the  ATCRBS  ID  code.  If  this  is  inconclusive,  the  logic 
tries  to  match  the  system  responsible  (using  BIC  and  ATSID)  and 
the  resolution  advisory.  If  should  be  pointed  out  that  the 
correlation  of  remote  threats  is  attempted  primarily  as  a  matter 
of  efficiency,  and  success  is  not  critical. 

If  the  CIR  ATCRBS  Correlation  Routine  was  not  successful,  a  new 
REMA  entry  is  created  for  the  threat.  Finally,  the  ATCRBS  track 
block  row  is  deleted  and  the  threat  ID  is  replaced  with  a 
pointer  to  the  state  vector  or  REMA  entry  of  the  threat  aircraft. 

5.3.2  External  Pair  Deletion 


In  the  External  Pair  Deletion  Routine,  the  existing  pair  records 
involving  the  subject  aircraft  are  searched  for  external 
conflicts  for  which  there  are  no  corresponding  CIR  rows.  Such 
pair  records  are  deleted  whenever  possible;  otherwise,  the 
absence  of  a  resolution  advisory  for  the  subject  aircraft  is 
recorded  in  the  conflict  table.  Figure  5-8  gives  the  flow  chart 
of  the  External  Pair  Deletion  Routine. 

In  genera],  a  pair  record  can  be  deleted  when  no  resolution 
advisory  is  recorded  for  either  aircraft  and  the  local  site  is 
not  attempting  to  uplink  a  null  resolution  advisory  (i.e., 
neither  SEND  flag  is  set).  The  Pair  Record  Deletion  Routine  is 
described  in  Section  13.2.  Conflicts  resolved  by  BCAS  are 
handled  in  a  special  manner.  Instead  of  deleting  the  pair 
record  as  soon  as  the  resolution  advisories  have  disappeared, 
the  BIC  variable  is  used  to  maintain  the  pair  record  until 
resolution  advisories  have  been  absent  for  BDROP  successive 
scans.  This  feature  ensures  that  ATARS  will  not  "jump  in" 
because  of  surveillance  differences  or  tracker  lag  and  uplink 
final  resolution  advisories  for  a  conflict  which  BCAS  has 
already  resolved. 
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For  external  pair  records  which  are  not  deleted,  the  sector  ID 
must  be  updated.  This  is  done  by  the  Update  Sector  ID  Routine, 
described  in  Section  5.3.5.  Also,  it  should  be  pointed  out  here 
that  whenever  a  resolution  advisory  field  is  initialized, 
changed,  or  erased  in  a  pair  record,  the  appropriate  intermediate 
maneuver  table  and  conflict  table  entries  must  also  be  updated. 
(These  data  structures  are  described  in  Section  9.1). 

5.3.3  External  Pair  Updating 

The  External  Pair  Updating  Routine  is  given  in  Figure  5-9.  The 
purposes  of  this  routine  are  to  update  the  ATARS  conflict  data 
for  existing  external  pairs  and  to  create  new  pair  records  for 
external  conflict  pairs  discovered  for  the  first  time  on  this 
downlink.  If  the  row  ID  for  a  new  external  pair  matches  the 
local  site  ID,  the  "external"  bit  is  set  in  ATSID  to  distinguish 
this  pair  from  those  being  resolved  by  the  local  site.  (This  is 
important  for  the  backup  mode  of  operation.)  If  a  new  conflict 
table  entry  is  created  for  a  threat,  the  ACID  field  in  the 
conflict  table  entry  is  initialized  to  point  to  the  state  vector 
or  remote  list  entry  of  the  threat.  If  the  threat  is  remote, 
REMFLG  is  set  and  CTE  and  CTPTR  are  initialized  in  the  remote 
list  entry.  Also,  see  the  programming  notes  in  Section  9.7 
pertaining  to  the  creation  of  pair  records. 

The  pair  record  sector  ID  for  new  and  existing  external  pairs  is 
updated  by  the  Update  Sector  ID  Routine  (described  in  Section 
5.3.5).  This  is  followed  by  the  updating  of  the  "system 
responsible"  data  (BIC  and  ATSID).  Next,  the  resolution 
advisory  for  the  subject  aircraft  is  updated  in  the  conflict 
table,  and  the  POSCMD  and  TSTART  variables  are  set.  A  value  of 
0  for  TSTART  implies  a  value  less  than  any  actual  clock  value  to 
which  TSTART  might  be  compared.  It  should  be  noted  that  the 
internal  ATARS  representations  of  resolution  advisories  are 
different  than  those  used  in  the  CIR  format.  Therefore,  a 
translation  is  implied  when  comparing  or  copying  advisories 
between  a  conflict  table  and  a  CIR  row.  Table  10-3  shows  the 
translation  between  the  two  formats.  Finally,  if  the  subject 
aircraft  is  controlled,  then  PIFR  is  set  and  a  check  of  other 
pair  records  involving  the  subject  aircraft  is  made  to  identify 
any  internal  pairs  where  only  an  uncontrolled  threat  has  a 
resolution  advisory.  In  such  an  instance,  a  potential 
incompatibility  exists,  and  POSCMD  is  set  to  a  negative  value  to 
force  recomputation  of  the  advisories  for  the  internal  pair. 

5.3.4  Internal  Pair  Updating 

The  Internal  Pair  Updating  Routine  is  flow  charted  in  Figure 
5-10.  Its  primary  functions  are  to  record  the  acceptance  or 
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rejection  of  resolution  advisories  uplinked  by  the  local  site 
and  to  record  the  delivery  of  null  resolution  advisories  and 
handoff  messages.  The  uplinked  resolution  advisories  are  found 
(by  locating  the  uplink  message  structure  pointed  to  by  UPMES1) 
and  examined  one  at  a  time. 

If  a  row  already  exists  for  the  current  threat  and  either  the 
B-Bit  is  set  or  the  row  ID  is  not  equal  to  the  local  site  ID, 
then  it  is  assumed  that  BCAS  or  another  site  stepped  in  first  to 
resolve  the  conflict,  and  the  pair  record  transitions  to  external 
status.  As  was  pointed  out  earlier,  the  comparison  and  copying 
of  resolution  advisories  from  CIR  rows  and  uplink  messages  on 
the  one  hand,  and  pair  records  on  the  other,  implies  a  transla¬ 
tion  process.  This  translation  is  shown  in  Table  10-3. 

If  a  handoff  message  has  been  accepted  by  the  aircraft,  this 
fact  is  recorded  by  resetting  the  SEND  flag  for  the  subject 
aircraft.  If  the  aircraft  is  no  longer  in  the  local  ATARS 
service  zone  and  no  more  handoff  messages  are  to  be  uplinked,  a 
message  is  sent  to  DABS  to  stop  ATARS  service  to  the  aircraft. 

For  most  of  the  uplinked  resolution  advisories,  the  local  site 
will  have  had  the  right  to  update  the  CIR.  That  is,  either 
there  was  no  previous  CIR  row,  or  the  responsibility  field  (RRS) 
indicated  local  site  responsibility  or  a  handoff  condition.  For 
these  cases,  the  uplinked  advisory  is  checked  for  compatibility 
with  all  existing  CIR  rows.  (See  the  compatibility  table  in 
Section  10.)  If  the  uplinked  resolution  advisory  is  found  to  be 
incompatible  (indicating  rejection  by  the  avionics),  the 
conflict  table  is  updated  by  restoring  the  previous  advisory 
from  the  corresponding  CIR  row  (if  any).  POSCMD  is  set  to  a 
negative  value  to  force  recomputation  of  the  resolution 
advisories.  If  the  uplinked  advisory  has  been  accepted,  the 
advisory  is  copied  into  the  CIR  row  (if  any)  in  temporary 
storage.  Acceptance  of  a  null  resolution  advisory  causes  any 
existing  CIR  row  to  be  deleted  from  temporary  storage,  the  SEND 
flag  to  be  reset  for  the  subject  aircraft,  and  the  pair  record 
to  be  deleted  whenever  possible.  (The  Pair  Record  Deletion 
Routine  is  described  in  Section  13.2.) 

After  the  Internal  Pair  Updating  Routine  has  been  executed,  the 
temporary  storage  area  occupied  by  the  downlinked  CIR  can  be 
released. 

5.3.5  Update  Sector  ID 


The  sector  ID  for  internal  pair  records  is  normally  initialized 
by  the  Master  Resolution  Task  at  the  time  of  pair  record  creation 
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and  updated  by  the  Seam  Pair  Task.  For  external  pair  records, 
however,  SECTID  is  updated  during  CIR  processing  by  the  Update 
Sector  ID  Routine,  shown  in  Figure  5-11.  This  routine  always 
sets  SECTID  equal  to  the  sector  ID  of  one  of  the  aircraft  from 
its  state  vector.  If  only  one  aircraft  has  a  state  vector  or  if 
both  aircraft  are  in  the  same  ATARS  sector,  the  choice  is  an 
easy  one.  If  the  aircraft  are  in  different  sectors,  however, 
the  following  strategy  is  used:  If  the  aircraft  are  less  than 
three  sectors  apart,  the  leading  (earlier)  aircraft  sector  ID  is 
chosen.  If  the  aircraft  are  three  or  more  sectors  apart,  the 
trailing  (later)  aircraft  sector  ID  is  picked. 
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6.  AIRCRAFT  PROCESSING 


6.1  New  Aircraft  Processing 


The  selection  of  new  aircraft  to  be  added  to  the  ATARS  data  base 
is  made  in  the  Report  Processing  and  Track  Processing  Tasks. 
These  choices  are  conveyed  to  the  New  Aircraft  Processing  Task 
through  the  XINIT  list.  The  purpose  of  this  module  is  to  add 
all  aircraft  on  this  list  to  the  X-list  or  EX-list  and  to 
initialize  all  parameters  in  the  state  vector  that  are  used  in 
subsequent  ATARS  processing  tasks. 


The  XINIT  list  is  a  linked  list  of  all  aircraft  that  have  been 
designated  for  addition  to  the  X-list  or  EX-list  by  the  Track 
Processing  Task  for  a  particular  ATARS  sector.  This  list  has  a 
pointer  to  the  head  of  the  list  and  is  linked,  in  one  direction 
only,  through  the  NEXTX  position  in  the  state  vectors.  The  use 
of  NEXTX  is  legitimate  at  this  time  because  this  field  is  not 
used  for  those  aircraft  not  yet  added  to  the  X-list  or  EX-list. 
In  this  module,  aircraft  from  the  XINIT  list  have  their  NEXTX 
and  PREVX  pointers  set  to  include  their  state  vectors  in  the 
forward  and  backward  linked  X-list  or  EX-list. 


The  flow  chart  of  the  New  Aircraft  Processing  Task  is  given  in 
Figure  6-1.  This  task  uses  the  Initial  Entry  of  Aircraft  Into 
X- 1 is t/Ex- 1  is t  Routine  which  is  described  in  Section  6.4.1. 


6.2  Aircraft  Update  Processing 

The  function  of  the  Aircraft  Update  Processing  Task  is  to  update 
the  position  and  velocity  coordinates,  determine  the  ATARS 
service  zone  through  the  Geographical  Processing  Routine 
(Section  6.3)  and  update  the  position  on  the  X/EX-list  (Section 
6.4)  of  all  aircraft  in  a  particular  sector  as  designated  by  the 
executive  control.  The  position  coordinates  of  the  hub  area 
aircraft  are  also  updated  as  part  of  this  task.  The  flow  chart 
of  the  Aircraft  Update  Processing  Task  is  given  in  Figure  6.2. 

Aircraft  update  processing  operates  on  a  particular  sector  list 
of  aircraft  threaded  in  the  X-list  and  EX-list.  The  start 
pointers  (SIDSPX,  SIDSPE)  for  the  sector  lists  are  in  a  table 
maintained  by  the  executive  control  and  are  updated  in  the 
X/EX-list  Update  Routine  (Section  6.4.2).  The  table  contains 
all  the  start  pointers  for  every  sector  on  the  X/EX-lists  and 
null  pointers  for  sectors  which  contain  no  aircraft.  The  start 
pointers  identify  the  state  vectors  of  the  aircraft  that  starts 
the  string  of  aircraft  for  a  sector. 
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The  position  coordinate  update  is  achieved  by  a  linear  projection 
from  the  aircraft's  predicted  position,  for  a  time  equal  to  the 
difference  between  the  sector  time  (TEN)  and  the  aircraft  time  of 
prediction  (TMP)  using  the  aircraft  external  velocity  com¬ 
ponents.  All  aircraft  are  then  presented  for  sector  processing 
on  a  common  basis.  It  is  important  to  note  that  the  only  coord¬ 
inate  used  in  ATARS  sector  processing  after  the  Aircraft  Update 
Processing  Task  is  complete  are  the  position  (X,Y,Z)  and  velocity 
(XD,YD,ZD)  coordinates  set  in  this  task.  The  updated  coordinates 
are  used  to  update  the  geographical  zone  if  ATSS  is  set  and  the 
position  in  the  X-list  or  EX-list  for  the  subject  aircraft  before 
continuing  with  the  next  aircraft  in  the  X-list  or  EX-list,  This 
process  continues  until  all  aircraft  in  the  sector  thread  for 
both  the  X-list  and  EX-list  are  completed. 

The  variables  TEN  and  TMP  will  have  a  fixed  number  of  bits. 

These  variables  will  recycle  to  zero  when  the  time  overflows  the 
number  of  available  bits.  Hence  in  subtracting  time  variables, 
here  and  throughout  the  ATARS  processing  both  variables  should  be 
expressed  with  common  higher  order  bits. 

Special  attention  must  be  given  to  the  structuring  of  the  update 
processing  task  because  the  X/EX-list  is  used  to  access  the 
aircraft  for  updating,  but  one  of  the  steps  in  updating  is  to 
reposition  tine  aircraft  in  the  X-list.  The  next  aircraft  in  the 
list  is  saved  and  stored  in  SAVPTR  before  the  current  aircraft  is 
repositioned  in  the  X-list.  However,  even  with  this  procedure, 
an  aircraft  which  has  moved  up  the  list  by  skipping  one  or  more 
aircraft  would  be  accessed  a  second  time  for  updating  in  the  same 
sector  updating.  To  prevent  this  duplicate  updating,  the  XUPFL 
in  the  state  vector  is  set  the  first  time  the  aircraft  is 
accessed  for  updating  and  is  read  to  prevent  duplicate  updating 
in  the  second  access.  The  XUPFL  flag  is  cleared  once  per  sector 
when  the  aircraft  is  accessed  in  the  Coarse  Screen  Processing 
Task. 

The  hub  area  position  coordinate  update  is  exercised  at  the  start 
of  every  quarter  cycle  (i.e.  when  the  antenna  is  at  00,  90°, 

180o(  270°).  The  hub  area  (Figure  3.2)  is  defined  as  a 
circle  of  given  radius  and  centered  at  the  DABS  sensor.  First, 
the  signpost  (explained  in  Section  6.4.1  -  Initial  Entry  of 
Aircraft  Into  the  X/Ex-list  Routine)  on  the  X/EX-list 
corresponding  to  the  negative  value  of  the  hub  area  radius  is 
located.  The  X/EX-list  is  searched  forward  until  the  signpost 
with  the  positive  value  of  the  hub  radius  is  reached.  All  of  the 
aircraft  identified  as  being  in  the  hub  (HUBFLG  set)  on  the 
X/EX-list  between  these  negative  and  positive  signposts  are 


r 


afforded  hub  processing.  The  position  and  velocity  coordinates 
of  these  aircraft  are  updated  using  the  same  technique  described 
above  for  the  regular  sector  aircraft  position  and  velocity 
updating.  This  processing  maintains  a  more  current  position  on 
the  X/EX-list  for  the  aircraft  located  near  the  DABS  sensor  and 
in  the  area  where  ATARS  sectors  are  not  very  wide.  This  is 
necessary  because  aircraft  may  change  sectors  rapidly  in  the  hub 
area  and  this  affords  a  more  timely  identification  of  a  possible 
conflict  in  the  ATARS  processor. 

Again,  the  XUPFL  flag  is  used  to  prevent  duplicate  updating. 

The  flag  is  reset  in  this  task  instead  of  waiting  for  the  Coarse 
Screen  Processing  Task  because  the  aircraft  identified  in  the 
hub  area  may  be  from  any  sector,  not  just  the  particular  sector 
be  i  ng 

processed  at  the  time.  Therefore,  not  all  the  XUPFL  flags  would 
be  reset  on  this  pass  through  the  ATARS  processor. 

6.3  Geographical  Processing 

This  routine  uses  geographical  mask  functions  to  manage  the  ATARS 
service  flag  (ATSS1),  BCAS  lockout  flag  (BCLO),  and  BCAS  service 
levels  for  suitably  equipped  aircraft.  The  masks  controlling 
these  services  are  tailored  to  each  specific  site.  Special 
treatment  is  provided  in  the  event  of  failure  of  a  neighboring 
ATARS.  The  flow  chart  is  shown  in  Figure  6-3. 

6.3.1  ATARS  Service  Mask 


An  ATARS  service  mask  contains  the  outer  limits  of  the  area  of 
this  site's  ATARS  service.  Backup  masks  are  stored  corresponding 
to  the  failure  of  each  neighboring  site.  These  are  selected  by 
the  backup  mode  logic  of  Section  13.9.  The  ATSS1  service  flag 
is  set  for  every  aircraft  in  the  service  area.  The  flag  is 
initially  set  by  the  Track  Update  Routine  (Figure  4-8)  when  the 
aircraft  first  enters  the  service  area. 

The  service  mask  should  be  implemented  as  a  pair  of  convex 
polygons,  one  for  aircraft  from  the  lower  limit  of  DABS  coverage 
up  to  and  including  altitude  HZONE,  and  the  other  for  aircraft 
above  altitude  HZONE.  These  polygons  may  have  as  many  vertices 
as  are  needed.  For  example,  to  implement  multiple  site  coverage 
in  a  large  area,  intricate  shapes  may  be  required  to  provide  the 
necessary  overlap  (seams)  and  divide  the  expected  traffic  and 
processing  load. 


It  is  essential  that  wherever  two  ATARS  sites  have  a  common 
boundary,  their  normal  mode  ATARS  service  areas  overlap  by  a 
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specified  distance.  This  overlap  is  called  a  seam  and  is  given 
a  width  sufficient  to  allow  nominal  warning  time  for  any  pair  of 
aircraft  on  opposite  sides  of  the  boundary.  The  seam  is  imple¬ 
mented  by  extending  each  site's  area  a  distance  DSEAMH  (or 
DSEAML)  past  the  nominal  boundary  of  the  high  (or  low)  altitude 
map.  Then  the  sites'  coverages  overlap  by  2*DSEAMH  for  the  high 
altitude  masks,  as  illustrated  in  Figure  6-4. 

The  following  algorithm  is  suggested  for  use  in  determining 
whether  the  tracked  aircraft  position  (XT,  YT)  lies  within  a 
convex  polygon.  This  figure  will  be  described  by  the  NVERT 
vertices,  (X^,Y^),  (X2 ,Y2 ),..., (^nvert* ^NVERt) •  The  vertices 
are  numbered  in  a  counterclockwise  manner  starting  at  any  vertex 
as  shown  for  the  example  4-sided  area  of  Figure  6-5.  Form  all 
vectors  joining  adjacent  vertices  in  a  counterclockwise  direction 
as  indicated  by  the  vectors  through  V^.  Also  form  all 
vectors  joining  the  vertices  to  the  point  (XT,  YT).  Let  these 
vectors  be  designated  VT^  through  VT^.  Then  the  point  (XT, 

YT)  is  internal  to  the  zone  if  and  only  if  all  vector  cross  pro¬ 
ducts  VTj*V1,VT2*V2, • • • ,VTNVERT*vNVERT>are  negative.  By 
precomputing  several  constants  which  are  functions  of  the  vertex 
coordinates,  the  number  of  calculations  required  to  perform  the 
test  can  be  reduced. 

A  typical  vector  cross  product,  VT£*V£  is, 

VTi  =  (XT-Xi)*(Yi+1-Yi)-(YT-Yi)*(Xi+1-Xi). 


This  can  be  written, 

VT^Vi  =  XT^DYi  -  YT*DX£+K^ 

where,  DX^  =  X£+j  -  X^ 

DYl  =  Yi+1  -  Yi 

=  Y^DXi  -  Xi*DY£ 

All  the  DX,  DY  and  K  constants  for  each  map  are  precomputed  and 
stored  in  memory.  Then  the  expression, 

XT*DYi-YT*DXi+Ki 

is  evaluated  repeatedly  from  i=  1  to  NVERT.  If  any  expression 
is  positive,  the  aircraft  is  outside  the  polygon.  If  all  are 
negative,  it  is  inside. 

6.3.2  The  Geographical  Zone  Indicator  (GEOG) 

The  site  ID  bits  in  an  aircraft's  CIR  provide  a  current 
indication  of  the  sites  providing  ATARS  service.  These  bits 
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allow  determination  of  the  aircraft's  placement  in  a  seam  between 
two  (or  more)  sites.  The  site  ID  bits  are  read  in  CIR  processing 
(Section  5.3)  and  saved  in  GE0G1 .  The  geographical  routine  looks 
for  own-site  ID  in  GE0G1 .  If  it  has  not  yet  been  uplinked,  it  is 
added  to  GE0G1  anyway,  to  enable  the  seam  pair  test  to  accept 
pairs  involving  this  aircraft. 

If  an  adjacent  site  has  failed  and  own-site  is  the  "master"  site 
for  this  failure,  own-site  continues  to  use  the  failed  site's  ID 
in  a  "center"  zone.  An  additional  masking  locates  aircraft  in 
the  proper  area  and  either  own  or  failed  site’s  ID  is  put  into 
GE0G1 .  Note  that  own  ID  is  not  removed  from  GE0G1  when  the 
aircraft  is  in  the  center  area,  for  own  ID  in  this  case  may  be 
due  to  a  remote  site  beyond  the  center  area  with  the  same  ID  as 
own- site. 

When  a  BCAS  equipped  aircraft  (indicated  in  ATSEQ1 )  is  inside 
the  ATARS  zone,  another  mask  is  performed  for  the  BCAS  lockout 
zone.  BCAS  is  locked  out  inside  most  of  the  ATARS  area,  but  is 
enabled  near  its  boundary  to  give  protection  from  "pop-ups" 
unseen  by  ATARS.  The  Start/End  BCAS  Lockout  Messages  to  DABS 
control  the  lockout  status  in  DABS’  surveillance  file.  These 
messages  need  not  be  repeated  every  scan. 

When  an  aircraft  previously  inside  the  ATARS  zone  is  first 
detected  outside  the  zone  by  geographical  processing,  ATSS1  is 
reset  and  the  coarse  screen  function  inhibits  further  conflict 
pair  detection.  DRATS1  is  set  to  notify  other  tasks  that  the 
aircraft  is  still  "visible"  and  able  to  receive  handoffs.  If 
the  aircraft  was  involved  in  any  seam  conflicts  controlled  by 
own-site,  the  handoff  bit  is  set  in  ATSID  and  the  adjacent  sites 
indicated  in  either  GE0G1  or  GE0G2  are  notified  by  ground  line. 
Conflict  pair  removal  will  remove  these  pair  records  when  appro¬ 
priate.  Own  ID  is  still  retained  in  ATSID  to  indicate  to  seam 
pair  test  that  the  handoff  was  from  own-site,  and  acceptance  of 
the  pair  is  not  allowed. 

6.4  X-List/EX-List  Updating 

The  X/EX-lists  are  two  lists  of  aircraft  which  are  ordered  on 
the  X-coordinates  of  the  aircraft  with  the  DABS  sensor  as  the 
center  point.  The  X-list  includes  all  aircraft  whose  altitude 
is  below  the  threshold  altitude,  ALO,  and  whose  speed  squared  is 
below  the  limit  SPL02.  All  other  aircraft  are  on  the  EX-list. 

The  position  of  the  aircraft  on  these  two  lists  is  checked  when 
the  particular  ATARS  sector  is  being  processed  and  it  is  updated 
if  required.  The  Initial  Entry  of  Aircraft  Into  the  X/EX-list 


Routine  (Section  6.4.1)  and  X/EX-list  Updating  Routine  (Section 
6.4.2)  describe  the  process  of  placing  aircraft  on  the  lists  and 
maintaining  their  current  position  on  the  lists. 

6.4.1  Initial  Entry  of  Aircraft  Into  the  X/EX-Lists 

Both  the  X-list  and  EX- list  are  modified  to  permit  expeditious 
entry  of  new  aircraft  into  the  ordered  list.  This  modification 
takes  the  form  of  seeding  the  ordered  X/EX-list  with  the  dummy 
state  vectors  which  have  fixed  X  coordinates.  A  cross-reference 
permits  a  direct  means  of  locating  the  dummy  state  vector  corre¬ 
sponding  to  a  given  X  coordinate.  The  cross-reference  takes  the 
form  of  an  array  of  pointers  linking  the  known  X  coordinates. 

The  dummy  state  vectors  are  called  signposts  and  contain,  as  a 
minimum,  fields  for  the  NEXTX  and  PREVX  pointers,  a  field  for 
the  X  value  of  the  signpost,  and  a  field  for  the  flag  to  identify 
signposts,  SPIDFG.  SPIDFG  will  be  permanently  set  for  all  sign¬ 
posts  and  reset  for  all  aircraft  state  vectors.  This  flag  is 
used  to  expedite  signpost  identification  in  the  Coarse  Screen 
Processing  Task. 

The  procedure  for  entering  a  new  aircraft  into  the  X-list  or 
EX-list  is  shown  in  Figure  6-6.  A  determination  is  first  made 
if  the  aircraft  is  in  the  hub  area.  If  so,  the  hub  flag  (HUBFLG) 
is  set.  If  the  aircraft  qualifies  for  the  EX-list,  the  aircraft 
is  entered  on  the  EX-list,  and  the  EXFLG  flag  is  set;  otherwise, 
it  is  entered  on  the  X-list  and  the  EXFLG  flag  is  reset.  Both 
the  X-list  and  EX-list  initially  consist  only  of  the  signposts 
linked  together.  The  NEXTX  and  PREVX  pointers  of  the  two  termi¬ 
nal  signposts  in  both  lists  are  set  to  null.  All  aircraft  may 
be  entered  into  the  X-list  or  EX-list  by  successive  use  of  this 
procedure. 

The  new  aircraft  are  linked  to  the  particular  ATARS  sector  list 
in  the  X/EX-list  corresponding  to  the  sector  identification 
(SVSID). 

The  ATARS  sector  thread  is  linked  only  in  the  forward  direction 
using  a  pointer  NEXTA.  If  the  new  aircraft  become  the  first 
aircraft  in  a  sector  thread,  the  executive  program  must  be 
notified  so  that  the  SIDSPX  and  SIDSPE  table  is  updated  to 
reflect  this  change.  When  threading  in  new  aircraft  to  a  sector 
list,  care  must  be  taken  to  remember  the  previous  aircraft  posi¬ 
tion  on  the  list,  as  a  backwards  pointer  is  not  required  for  the 
ATARS  processing  and  thus  not  maintained  as  part  of  the  state 
vector. 
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INITIAL  ENTRY  OF  AIRCRAFT  INTO  X-LIST/EX-U8T  ROUTINE  (tog*  1  Of  3) 
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6.4.2  X-List/EX-List  Updating 


The  procedure  for  updating  the  X/EX-lists  is  shown  in  Figure 
6.7.  The  EXFLG  (set  for  the  EX-list  aircraft)  is  used  to 
determine  on  which  list  an  aircraft  appeared  on  the  last  cycle. 

If  the  aircraft  has  crossed  the  altitude  or  speed  threshold, 
then  that  aircraft  is  removed  from  the  X-list  or  EX-list  and 
entered  into  the  other  list  using  the  Initial  Entry  of  Aircraft 
Into  the  X/EX-list  Routine  (Section  6.4.1).  If  the  aircraft  has 
not  crossed  the  thresholds,  then  its  position  in  the  X/EX-list 
is  updated  according  to  its  present  X  coordinate.  At  the  same 
time,  the  aircraft  position  in  the  ATARS  sector  list  is  updated 
to  correspond  to  the  present  X  coordinate.  If  the  new  position 
in  the  sector  list  is  the  first  position  in  the  sector  list,  the 
executive  program  must  be  notified  to  set  SIDSPX  or  SIDSPE 
correctly. 

6.5  Coarse  Screen  Processing 

The  Coarse  Screen  Processing  Task  is  an  operation  applied  to  a 
single  aircraft  on  the  X-list  or  the  EX-list.  The  executive 
program  points  to  the  initial  aircraft  for  a  particular  sector's 
list  on  the  X/EX-list  and  coarse  screening  then  steps  through 
the  list,  processing  all  the  aircraft  on  the  sector  list.  The 
purpose  of  coarse  screen  filtering  is  to  identify  aircraft  which 
may  be  in  conflict  with  the  subject  aircraft.  This  is  done  by 
computing  X,  Y,  and  Z  search  limits  for  a  sector  subject  aircraft 
and  then  testing  all  aircraft  in  the  appropriate  linked  list, 
which  fall  within  the  X-limit  against  the  Y  and  Z  search  limits, 
and  a  Z  rate  test.  By  segregating  aircraft  through  the  use  of 
the  X-list  and  the  EX-list,  it  is  possible  to  construct  a  coarse 
screening  procedure  that  can  provide  ample  warning  times  for 
aircraft  with  exceptionally  high  speeds  (those  on  the  EX-list) 
without  requiring  unnecessarily  large  search  volumes  for  the 
majority  of  the  aircraft  which  are  on  the  X-list. 

The  ATARS  program  uses  larger  look-ahead  times  for  pairs 
involving  controlled  aircraft  than  for  pairs  involving  only 
uncontrolled  aircraft.  Since  the  greatest  number  of  aircraft  is 
expected  to  be  uncontrolled,  a  significant  savings  in  computa¬ 
tional  requirements  is  achieved  by  using  a  separate  coarse 
screening  procedure  with  larger  search  limits  for  controlled 
aircraft.  For  coarse  screening  of  uncontrolled  subject  aircraft 
on  the  X-list,  only  other  uncontrolled  aircraft  with  X  coord¬ 
inates  greater  than  the  X  coordinate  of  the  subject  aircraft  are 
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FIGURE  »-7 

X-UST/EX-I.IST  UPOATINO  ROUTINE  (Pag*  1  at  9) 
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FIGURE  8-7 

X-IMT/IX-UST  UPDATING  ROUTINE  (Pag*  2  el  1) 
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examined.  This  constitutes  a  one-way  search,  in  which  only 
uncontrolled/uncontrolled  potential  conflicts  are  investigated. 
For  controlled  subject  aircraft,  a  two-way  search  of  the  X-list 
is  used.  When  the  search  is  made  in  the  positive  X  direction, 
all  controlled  and  uncontrolled  aircraft  are  investigated,  and 
when  the  search  is  made  in  the  negative  X  direction,  only  the 
uncontrolled  aircraft  are  investigated.  This  avoids  a  duplicate 
declaration  of  controlled/controlled  conflicts.  The  overall 
process  is  shown  for  the  X-list  and  the  EX-list  aircraft  in 
Figure  6-8. 

As  shown  in  Figure  6-9,  the  search  region  implied  by  a  given 
aircraft  is  computed  as  the  outer  bounds  of  either: 

1.  a  region  given  by  the  coarse  screen  proximity  advisory 
search  criterion  (this  region  is  the  same  for  both  a 
controlled  and  an  uncontrolled  subject  aircraft)  or 

2.  a  region  based  on  a  time  projection  using  the  subject 
aircraft  tracked  velocities  and  the  largest  look-ahead  time 
appropriate  for  the  subject  aircraft,  and  assuming  the 
intruding  aircraft  to  have  maximum  velocity  (240  knots  low 
altitude,  600  knots  high  altitude). 

The  search  limits  so  obtained  will  then  permit  detection  of 
proximity  advisories  or  any  of  the  other  messages  which  are 
based  on  the  tau  criterion.  For  the  nominal  values  of  para¬ 
meters  given  in  Figure  6-9,  a  240  knot  maximum  speed  has  been 
assumed. 

The  detailed  flow  chart  of  the  Coarse  Screen  Processing  Task  is 
shown  in  Figure  6-10.  Parameters  and  variables  used  in  Figure 
6-10  are  listed  in  Tables  6-1  and  6-2.  The  coarse  screen  resets 
the  XUPFL  flag  for  the  subject  aircraft  which  is  used  in  the 
Aircraft  Update  Processing  Task  to  prevent  multiple  updates 
during  repositioning  of  aircraft  on  the  X/EX-lists.  It  is 
convenient  to  do  this  in  coarse  screening  when  each  aircraft  in 
the  sector  list  is  being  accessed  for  coarse  screening,  rather 
than  requiring  a  separate  pass  through  the  X-list  and  EX-list 
specifically  to  reset  this  flag. 

Coarse  screening  involves  searching  along  a  linked  list  from  the 
position  of  the  aircraft  undergoing  coarse  screening  to  the 
upper  and  lower  (if  appropriate)  X-limit.  X-list  aircraft  are 
checked  against  other  X-list  aircraft  only.  EX-list  aircraft 
are  checked  against  EX-list  aircraft  and,  if  their  altitude  and 
vertical  rate  warrant,  against  X-list  aircraft.  By  using  the 
signpost  identifier  flag  (SPIDFG),  subject  aircraft  do  not  have 
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FIGURE  6-8 

DESCRIPTION  OF  COARSE  SCREEN  PROCESSING  TASK 
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FIGURE  6-10 

COARSE  SCREEN  PROCESSING  TASK  (Page  1  ol  8) 


FIGURE  8-10 

COARSE  SCREEN  PROCESSING  TASK  (Paao  2  of  8) 
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FIGURE  6-10 

COARSE  SCREEN  PROCESSING  TASK  (Pag*  7  of  0) 
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TABLE  6-1 


PARAMETERS 

SYMBOL 

AHI 

RMAX 

RMAXH 

RMAX  I 

RMAXV 

RPWI 

TLA 

TLI 

TLV 

VPCS 

XSP 

ZFAST 


USED  IN  COARSE  SCREEN  PROCESSING  TASK 


USE 

Altitude  threshold  for  search 
of  X-list  with  aircraft  from 
EX- list. 

Maximum  distance  traveled 
by  an  aircraft  over  the  longest 
appropriate  system  look-ahead 
time. 

RMAX  to  be  used  for  all  searches 
on  the  EX-list. 

RMAX  to  be  used  with  a 
controlled  subject  aircraft. 

RMAX  to  be  used  with  an  uncontrolled 
subject  aircraft. 

Maximum  separation  between 
aircraft  for  a  proximity 
advisory. 

Largest  appropriate  look-ahead 
time. 

TLA  to  be  used  with  a 
controlled  subject  aircraft. 

TLA  to  be  used  with  an 
uncontrolled  subject  aircraft. 

Vertical  proximity  test  limit. 

Nominal  signpost  X  distance. 

Z  velocity  threshold  for 
non-subject  aircraft. 


FLOW  CHART 

NOMINAL  VALUE 
12,000  ft 


20  nmi 

8  nmi 

5  nmi 

4  nmi 


120  sec 

75  sec 

2,000  ft 
5  nmi 
1,000  fpm 
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TABLE  6-2 


VARIABLES  USED  IN  COARSE  SCREEN  PROCESSING  TASK  FLOW  CHART 


SYMBOL 
XP,  YP,  ZP 


XL,  XU 
YL,  YU 
ZL,  ZU 


USE 

Projected  location  of  aircraft  after 
longest  appropriate  look-ahead  time 
(TLA). 

Lower  and  upper  X  search  limits. 
Lower  and  upper  Y  search  limits. 
Lower  and  upper  Z  search  limits. 

The  null  pointer. 


NULL 


r 


to  be  checked  against  those  marked  in  the  X/EX-lists.  For  all 
aircraft  encountered  in  these  searches,  the  Y  and  Z  limit  tests 
and  the  Z  rate  limit  test  are  applied.  If  these  tests  show  a 
possible  conflict,  then  a  pair  of  aircraft  which  requires 
further  processing  has  been  identified.  This  pair  of  aircraft 
is  entered  on  the  Coarse  Screen  Pair  List  for  the  this  sector. 

Any  individual  aircraft  is  included  on  only  the  X-list  or 
EX-list.  Hence,  when  an  aircraft  on  the  EX-list  must  be  tested 
against  aircraft  on  the  X-list,  special  provisions  must  be  made 
for  finding  the  place  on  the  X-list  to  begin  the  search.  A 
procedure  analogous  to  that  used  for  initial  entry  on  the  X-list 
is  used  in  which  the  first  signpost  below  the  aircraft's  X 
position  is  obtained  and  the  X-list  entered  at  that  point.  It 
is  not  important  to  locate  the  subject  aircraft's  exact  position 
on  the  X-list;  it  is  sufficient  to  obtain  an  entry  point  between 
the  upper  and  lower  limits.  If  the  distance  between  signposts 
is  small  enough,  this  will  happen  automatically.  Even  if  an 
entry  point  to  the  X-list  were  used,  which  fell  outside  the 
X-limits,  the  procedure  would  work  correctly  but  would  be 
inefficient  since  more  aircraft  than  necessary  would  be  tested 
in  coarse  screening. 

6.6  Terrain/Airspace/Obstacle  Avoidance 

The  capability  to  provide  an  alert  for  the  violation  of 
restricted  airspace,  close  proximity  to  the  terrain,  and  close 
proximity  to  an  obstacle  is  provided  by  this  task.  This  task 
requires  an  ordered  X-list  before  it  can  operate  on  the  sector 
of  aircraft  under  consideration.  The  logic  to  determine  the 
need  for  an  alert  is  provided  here  while  the  actual  construction 
of  the  message  is  performed  by  the  Data  Link  Message  Construction 
Task.  The  Terrain/Airspace/Obstacle  Avoidance  Task  is  presented 
in  Figure  6-11.  Only  aircraft  which  are  in  the  ATARS  service 
area  are  eligible  for  processing. 

6.6.1  Terrain  Avoidance  Processing 

The  Terrain  Avoidance  Routine  is  described  in  Figure  6-12.  The 
Mode  C  barometric  pressure  correction  is  provided  with  the 
surveillance  report.  Aircraft  which  are  on  final  approach  will 
be  below  the  terrain  altitude  threshold  for  the  final  phase  of 
flight.  Therefore,  a  special  check  is  required  to  inhibit 
alerts  if  aircraft  are  on  the  final  approach  glide  slope. 


The  real  time  processing  of  the  map  of  the  terrain  is  similar  to 
the  method  used  in  the  Terminal  Area  Minimum  Safe  Altitude 


FIGURE  8-1 1 

TERRAIN/AIRSPACE/OBSTACLE  AVOIDANCE  TASK 
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CONTROLLED  OR  EQUIPPED  AIRCRAFT 


FIGURE  H* 

TERRAIN  AVOIDANCE  ROUTINE 


V 


Warning  (MSAW)  function  described  in  Reference  7.  A  major 
difference  concerns  the  use  of  a  grid  map  with  variable  bin 
sizes  and  the  associated  indexing  required  to  access  the 
altitude  threshold  for  each  high  level  and  sub-level  terrain 
bin.  Figure  6-13  presents  the  logic  to  access  the  terrain  map, 
project  (horizontally)  the  aircraft,  determine  the  bin  altitude 
threshold,  and  compare  the  threshold  to  the  aircraft  altitude. 
Figure  6-14  gives  an  example  of  the  bins  to  be  checked.  Table 
6-3  summarizes  the  altitude  checks  required  for  each  event  in 
the  projection  of  the  aircraft. 

The  off-line  generation  of  the  terrain  map  is  described  in 
Figure  6-15.  This  procedure  is  identical  to  the  method  used  in 
Reference  7  with  the  exception  of  the  sub-level  indexing  and  the 
marking  of  bins  which  are  in  a  final  approach  zone.  A  data 
structure  implementation  for  the  terrain  map  is  presented  in 
Figure  6-16. 

6.6.2  Obstacle  Avoidance  Processing 

Figure  6-17  presents  the  routine  for  obstacle  avoidance 
processing.  This  logic  is  only  applied  to  aircraft  which  are 
below  a  minimum  altitude.  An  X -ordered  linked  list  of  obstacles 
is  generated  off-line  and  stored  for  access  by  the  Obstacle 
Avoidance  Routine.  This  list  will  contain  position  and  altitude 
information  for  each  obstacle.  Proximity  to  an  obstacle  is 
determined  by  adding  an  X,  Y,  Z  system  parameter  to  the  position 
data  in  the  direction  of  the  velocities  of  the  respective  data. 

A  check  for  convergence  with  the  obstacle  is  made  before  issuing 
an  alert. 

6.6.3  Restricted  Airspace  Avoidance  Processing 

The  Restricted  Airspace  Avoidance  Routine  is  presented  in  Figure 
6-18.  This  logic  consists  of  two  major  elements,  1)  providing 
an  advisory  to  uncontrolled  aircraft  upon  first  entry  into  a 
Terminal  Control  Area  (TCA)  and,  2)  providing  on  alert  to  any 
aircraft  which  has  entered  an  area  of  restricted  airspace.  The 
technique  for  storage  and  access  of  the  TCA  map  should  allow 
effective  use  of  the  ATARS  processors.  The  storage  of  the 
restricted  airspace  areas  and  the  logical  checks  for  determining 
if  an  aircraft  is  inside  an  area  is  the  same  as  that  described 
for  processing  of  airport  area  types  (see  Section  7.1.4). 
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TABLE  6-3 

TERRAIN  ALTITUDE  CHECKS 


Event 

Altitude  Checks 

Check  Aircraft  Z  Against 

Start  or  End  of 
Projection  Point 

1.  Current  bin  Z  threshold 

2.  Adjacent  bin(s)  Z  threshold 

X-line  cross 
point 

1.  New  bin  Z  threshold 

2.  If  negative  ZDOT:  Z  threshold 
of  previous  bin  (use  aircraft 

Z  at  X-line  cross  point) 

3.  Adjacent  bin(s)  Z  threshold 

Y-line  cross 
point 

1.  New  bin  Z  threshold 

2.  If  negative  ZDOT:  Z  threshold 
of  previous  bin  (use  aircraft  Z 
at  Y-line  cross  point) 

3.  Adjacent  bin(s)  Z  threshold 

LOAD  U.S.  GEOC 
TAPE  OF  DIGITIZED 
TERRAIN  DATA  (DTD) 


X,  Y  COORDINATES 
OF  TOPOGRAPHICAL 
DATA  IN  COORD 
SYSTEM  OF  RADAR 
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CONFLICT  PAIR  DETERMINATION  AND  DISPOSITION 


Two  Casks  are  discussed  in  this  section,  the  Detect  Task  and  the 
Seam  Pair  Task.  These  functions  are  to  examine  screened  aircraft 
pairs  for  potential  conflict  situations  and  to  determine  the  type 
of  subsequent  ATARS  processing.  The  Detect  Task  determines  if 
an  aircraft  pair  requires  further  ATARS  action  (controller 
alert,  proximity,  threat  or  resolution  advisory),  while  the  Seam 
Pair  Task  determines  which  ATARS  site  has  responsibility  for  the 
pair,  the  file  disposition  of  the  pair  and  consequently  the  type 
of  further  ATARS  processing. 

The  main  body  of  the  succeeding  pages  of  Section  7  are  tables 
and  figures.  It  is  intended  that  a  study  of  these  charts  alone 
will  impart  all  that  is  necessary  to  know  the  specifications  of 
the  two  tasks  mentioned,  with  the  text  serving  a  supporting 
role.  As  such,  a  description  of  the  organization  of  charts  and 
figures  is  pertinent. 

Figure  7-1  is  a  descriptive  flow  chart  of  the  main  elements  of 
the  Detect  Task.  Figure  7-2  gives  the  specifications  of  the 
Detect  Task  on  a  programmable  level.  The  following  Figures,  7-3 
through  7-15,  are  flow  charts  of  all  supporting  routines 
referenced  in  Figure  7-2  by  a  process  block  containing  the 
routine  name  underlined.  The  remaining  figure,  7-16,  is  the 
flow  chart  for  the  Seam  Pair  Task.  Table  7-1  through  7-3  relate 
(1)  equipage  and  control  state  of  an  aircraft  with  the  possible 
flag  settings  that  are  the  primary  output  of  the  detection 
function,  (2)  these  flags  with  the  routine  that  determines  them 
and  (3)  the  routines  called  depending  on  an  aircraft  pair 
state.  A  study  of  these  tables  will  help  in  explaining  the 
decision  diamonds  in  the  preceding  flow  charts.  Tables  7-4 
through  7-12  state  recommended  system  parameter  values  for 
variables  referenced  in  the  flow  charts.  Table  7-11  summarizes 
all  such  parameters  and  the  routines  which  utilize  them.  The 
last  table,  7-12,  specifies  the  information  needed  for  further 
processing  of  the  conflict  pair  after  the  Detect  Task  is 
complete.  The  trailing  text  is  a  summary  of  the  two  tasks, 

Detect  and  Seam  Pair.  The  reader  who  desires  an  overview  should 
examine  the  text;  Tables  7-1,  7-2,  7-3;  Figures  7-1,  7-16;  and 
possibly  Figure  7-2. 

7.1  Detection 


The  Detect  Task,  given  a  pair  of  aircraft,  their  position, 
velocity,  flight  status  and  equipage,  determines: 
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TABLE  7-1 


FLAGS  APPROPRIATE  FOR  A  PARTICULAR  AIRCRAFT  STATE 


UNEQUIPPED/UNCONTROLLED  -  none 

UNEQUIPPED/CONTROLLED  -  CAP LG,  ICAFLG 

EQUIPPED/UNCONTROLLED  -  CMDFLG,  FPWFLG,  PWIFLG 

EQUIPPED/CONTROLLED  -  IFRFLG,  FPIFLG,  CMDFLG,  PWIFLG, 

CAFLG,  ICAFLG 
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TABLE  7-2 


ROUTINE  AND  DETECT  FLAG  CROSS-REFERENCE  TABLE 


FLAG 

ROUTINE  MODULE  WHICH  MAY  SET 

MTTFLG 

SMTTF,  SCMDF ,  SI FRF 

PWIFLG 

SPWIF 

FPWFLG 

MTT*,  SFPWF 

FPIFLG 

MTT*,  SFPIF 

CMDFLG 

MTT*,  SCMDF 

IFRFLG 

MTT*,  SIFRF 

CAP  LG 

SCAFLG 

ICAFLG 

SCAFLG 

FLAG 


*  See  text  for  explanation 
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TABLE  7-3 

AIRCRAFT  PAIR  STATE  AND  ROUTINE  CROSS-REFERENCE  TABLE 


EQ/EQ 

UNEQ/UNEQ 

UNEQ/EQ 

UNC/UNC 

SENAT,  SETPAR 
SFPWF,  SCMDF 

SPWIF 

None 

SENAT,  SETPAR 
SFPWF,  SCMDF 
SPWIF,  SMTTF 

CONT /CONT 

SENAT,  SETPAR, 
SCAFLG,  SFPIF 
SIFRF,  SPWIF 

SENAT,  SETPAR 
SCAFLG 

SENAT,  SETPAR 
SCAFLG,  SFPIF 
SIFRF,  SPWIF 
SMTTF 

UNC /CONT 

SENAT,  SETPAR 
SCAFLG,  SFPWF 
SCMDF,  SFPIF 
SIFRF,  SPWIF 

SENAT,  SETPAR 
SCAFLG 

SENAT,  SETPAR 
SCAFLG,  SFPIF 
SIFRF,  SPWIF 
SMTTF 

CONT /UNC 

SENAT,  SETPAR 
SCAFLG,  SFPWF 
SCMDF,  SFPIF 
SIFRF,  SPWIF 

SENAT,  SETPAR 
SCAFLG 

SENAT,  SETPAR 
SCAFLG,  SFPWF 
SCMDF,  SPWIF 
SMTTF 

UNC  -  UNCONTROLLED  EQ  -  EQUIPPED 
CONT  -  CONTROLLED  UNEQ  -  UNEQUIPPED 
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TABLE  7-4 
PREPAR  PARAMETERS 


AREA  TYPE 

TWARN 

4 

44.8  sec 

3 

36.8  sec 

2 

36.8  sec 

1 

36.8  sec 

AREA  TYPE 

RCONTH 

ACONTH 

3  or  4 

1 . 2  nmi 

375  ft 

2 

.75  nmi 

275  ft 

1 

.75  nmi 

275  ft 

VRZCON  =  -300  FPM 


TABLE  7-5 


SCAFLG  PARAMETERS 


AREA  TYPE 

RCON2 

AFC  ON 

MDCON2 

3  or  4 

1.44  nmi2 

375  ft 

1.44  nmi.2 

2 

.5625  nmi2 

275  ft 

.5625  nmi.2 

ZONE  TYPE 

ZRCON2 

ZAFCON 

2 

.25  nmi.2 

275  ft 
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TABLE  7-6 


CONTROLLED/UNCONTROLLED  TABLE  (CUTAB) 


MULT 

AREA  TYPE 

EQUIP 

S 

TFPWIV 

TFPWIH 

L 

( sec) 

U 

S 

TCMDV 

TCMDH 

L 

(sec) 

U 

LE3 

4 

BU 

0 

38 

68 

15 

38 

53 

LE3 

3 

BU 

0 

30 

60 

15 

30 

45 

LE3 

2 

BU 

0 

30 

60 

15 

30 

45 

LE3 

1 

BU 

0 

30 

60 

15 

30 

45 

LE3 

4 

CN 

0 

38 

68 

15 

38 

5 

LE3 

3 

CN 

0 

30 

60 

15 

30 

45 

LE3 

2 

CN 

0 

30 

60 

15 

30 

45 

LE3 

1 

CN 

0 

30 

60 

15 

30 

45 

GT3 

4 

BU 

0 

60 

68 

15 

60 

60 

GT3 

3 

BU 

0 

60 

68 

15 

60 

60 

GT3 

2 

BU 

0 

60 

68 

15 

60 

60 

GT3 

1 

BU 

0 

60 

68 

15 

60 

60 

GT3 

4 

CN 

0 

60 

68 

15 

60 

60 

GT3 

3 

CN 

0 

60 

68 

15 

60 

60 

GT3 

2 

CN 

0 

60 

68 

15 

60 

60 

GT3 

1 

CN 

0 

60 

68 

15 

60 

60 

TFIFRV 

TIFRV 

TFIFRH 

TIFRH 

S 

L 

U 

S 

L 

U 

LE3 

4 

BU 

0 

38 

68 

35 

38 

38 

LE3 

3 

BU 

0 

30 

60 

35 

30 

30 

LE3 

2 

BU 

0 

30 

60 

35 

30 

30 

LE3 

l 

BU 

0 

30 

60 

35 

30 

30 

LE3 

4 

CN 

0 

38 

68 

35 

38 

38 

LE3 

3 

CN 

0 

30 

60 

35 

30 

30 

LE3 

2 

CN 

0 

30 

60 

35 

30 

30 

LE3 

1 

CN 

0 

30 

60 

35 

30 

30 

GT3 

4 

BU 

0 

60 

68 

35 

60 

60 

GT3 

3 

BU 

0 

60 

68 

35 

60 

60 

GT3 

2 

BU 

0 

60 

68 

35 

60 

60 

GT3 

1 

BU 

0 

60 

68 

35 

60 

60 

GT3 

4 

CN 

0 

60 

68 

35 

60 

60 

GT3 

3 

CN 

0 

60 

68 

35 

60 

60 

GT3 

2 

CN 

0 

60 

68 

35 

60 

60 

GT3 

1 

CN 

0 

60 

68 

35 

60 

60 
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TABLE  7-6 


C0NTR0LLED/UNCONTRCT  LED  TABLE  (CUTAB) 
(Concluded) 


PARAMETER  MODULE  AREA  TYPE 


3  or  4 

2 

1 

RCMD2 

SCMDF 

1.0  nmi2 

.5625  nmi2 

.5625  nmi2 

AF 

SCMDF 

750  ft 

750  ft 

750  ft 

RIFR2 

SIFRF 

.5625nmi2 

.5625  nmi2 

.5625  nmi2 

AIFR 

SIFRF 

750  ft 

750  ft 

750  ft 

RFPWI2 

SFPWF 

1.44  nmi2 

.5625  nmi2 

.5625  nmi2 

AFPWI 

SFPWF 

1000  ft 

1000  ft 

1000  ft 

MDFPW2 

SFPWF 

1 . 44  nmi 2 

.5625  nmi2 

.5625  nmi2 

RFIFR2 

SFPIF 

1.44  nmi2 

.5625  nmi2 

.5625  nmi2 

AFIFR 

SFPIF 

1000  ft 

1000  ft 

1000  ft 

MDFPI2 

SFPIF 

1.44  nmi2 

.5625  nmi2 

.5625  nmi2 

NOTE:  Equipage 

is  keyed 

as  follows: 

BU  -  Either 

both  AC  e 

quipped  or  else  only 

uncontrolled 

AC 

equipped. 


CN  -  Either  controlled  AC  only  is  equipped  or  else  neither  AC 
is  equipped. 


Multiplicity  (MULT)  is  keyed  as  follows: 
LE  -  Less  than  or  equal  to 
GT  -  Greater  than 
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TABLE  7-7 


CONTROLLED /CONTROLLED  TABLE  (CCTAB) 


MULT 

AREA  TYPE 

TFIFRV 

TFIFRH 

TIFRV 

TIFRH 

S 

L 

U 

S 

L 

U 

(sec ) 

(sec) 

LE3 

4 

0 

38 

38 

35 

38 

38 

LE3 

3 

0 

30 

60 

35 

30 

30 

LE3 

2 

0 

30 

60 

35 

30 

30 

LE3 

1 

0 

30 

60 

35 

38 

38 

GT3 

4 

0 

60 

68 

35 

60 

60 

GT3 

3 

0 

60 

60 

35 

60 

60 

GT3 

2 

0 

60 

60 

35 

60 

60 

GT3 

1 

0 

60 

60 

35 

60 

60 

PARAMETER 

MODULE 

3  or  4 

AREA  TYPE 

2 

1 

RIFR2 

SI  FRF 

.5625  nmi^ 

.5625  nmi^ 

.5625  nmi^ 

AIFR 

SIFRF 

750  ft 

750  ft 

750  ft 

RFIFR2 

SFPIF 

.5625  nmi^ 

.5625  nmi^ 

.5625  nmi^ 

AFIFR 

SFPIF 

1000  ft 

1000  ft 

1000  ft 

MDFPI2 

SFPIF 

.5625  nmi^ 

.5625  nmj2 

.5625  nmi^ 

NOTE:  Parameters  with  (S,  L,  U)  designations  are  to  be  computed  as  follows: 

U 

Parameter  V  =  (TCONV  -  S)  l 

U 

Parameter  H  =  (TCONH  -  S)  L  »  where 

U 

TCONV,  TCONH  are  computed  in  PREPAR,  and  (  )  L  designates 

limit  of  (  )  to  U  above,  L  below. 


TABLE  7-8 


UNCONTROLLED/UNCONIROLLED  TABLE  (UUTAB) 


UUIND 

AREA  TYPE 

TFPWIH 

TCMDH 

TFPWIV 

1 

4 

53  sec 

38  sec 

1 

3 

45  sec 

30  sec 

1 

2 

45  sec 

30  sec 

1 

1 

45  sec 

30  sec 

2 

4 

53  sec 

38  sec 

2 

3 

53  sec 

38  sec 

2 

2 

53  sec 

38  sec 

2 

1 

53  sec 

38  sec 

PARAMETER 

MODULE 

AREA  TYPE 

3  or  4 

2 

RCMD2 

SCMDF 

1.0  nmi.2 

1.0  nmi2 

AF 

SCMDF 

750  ft 

750  ft 

RFPWI2 

SFPWF 

1.0  nmi2 

1.0  nmi2 

AFPWI 

SFPWF 

1000  ft 

1000  ft 

MDFPW2 

SFPWF 

1.2  nmi2 

1.2  nmi2 
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L 


TCMDV 


38  sec 
30  sec 
30  sec 
30  sec 
38  sec 
38  sec 
38  sec 
38  sec 


1 

1.0  nmi.2 

730  ft 
1.0  nmi^ 
1000  ft 

1<2  nmi.2 


TABLE  7-9 


ALTDP 

TVDP 

TDP 


ALTDP 

TVDP 

TDP 


UCMDT/CCMDT  PARAMETERS 


650  ft 

8.0  sec  UCMDT  Assignments 

23.0  sec 


650  ft 

8.0  sec  CCMDT  Assignments 

23.0  sec 
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TABLE  7-10 


SATAZ  and  FAZSET  PARAMETERS 


Airport  Area  Table 

NOI  -  dumber  of  type  1  areas  (site  specific) 

NOII  -  Number  of  type  2  areas  (site  specific) 

RDIST  =  83.3  nmi  (for  sensor  azimuth  jitter  of  .06°) 

ZHMNX,  ZHMXX,  ZHMNY,  ZHMXY  -  COARSE  SCREEN  PARAMETERS 

Al,  Bl,  Cl 
A2,  B2,  C2 
C3,  C4 
ZMIN,  ZMAX 

Dl,  El,  Fl  Allow  up  to  five  sets  for  each  type  1  area. 

An  aircraft  is  in  a  given  area  type  1  or  2  if  and  only  if  its  position 
(X,  Y,  Z)  satisfies: 

(1)  Cl  .LE.  (Al  *  X  +  Bl  *  Y)  .LE.  C2 

(2)  C3  .LE.  (A2  *  X  +  B2  *  Y)  .LE.  C4 

(3)  ZMIN  .LE.  Z  .LE.  ZMAX 

(4)  (Dl  *  X  +  El  *  Y)  .LE.  Fl  (for  area  type  1  only) 

Equation  (4)  is  a  generic  equation  to  be  satisfied  for  each  set  Dl , 
El,  F  associated  with  a  given  area  1.  In  addition,  each  area  type  1 
and  2  will  have  a  flag  (CAREQ)  indicating  whether  controller  alert 
processing  is  appropriate  for  that  particular  area  or  not. 

Each  group  of  defining  parameters  for  an  airport  type  1  or  2  will  have 
an  airport  name  associated  with  it.  This  name  allows  areas  from 
different  airports  to  be  differentiated  in  spatial  dependent  logic  in 
the  Detect  Task. 


One  set  for  each  type  1  and  type  2  area. 
Allow  for  25  sets. 


Airport  Zone  Table 

NOZl  -  Number  of  zone  1  areas  (site  specific) 

N0Z2  -  Number  of  zone  2  areas  (site  specific) 

ZJMNX,  ZJMXX,  ZJMNY,  ZJMXY  -  COARSE  SCREEN  PARAMETERS 

AZ0NL1 ,  AZ0NW1 
BZ0NL1,  BZ0NW1 
CZ0NL1,  CZ0NW1 
LZ0N1 ,  WZON1 ,  ZZ0N1 


One  set  for  each  zone  1.  Allow  for 
10  sets. 


TABLE  7-10 


SATAZ  and  FAZSET  PARAMETERS 
(Concluded) 


Airport  Area  Table 


AZONL2,  AZ0NW2 
BZ0NL2 ,  BZ0NW2 
CZONL2,  CZ0NW2 
LZ0N2,  WZ0N2 
AZ0NZ2,  BZ0NZ2 
CZ0NZ2,  DZ0NZ2 


One  set  for  each  zone  2.  Allow  for 
20  sets. 


ZZ0N2  =  200  ft 
COAA2  =  .9698 


An  aircraft  is  in  a  given  zone  1  if 

(1)  -WZON1  .LE. (AZONWl  *  X  +  BZONW1 

(2)  -LZON1  .LE. (AZ0NL1  *  X  +  BZONLt 

(3)  Z  .LE.  ZZON1 


its  position  (X,  Y,  Z)  satisfies: 

*  Y  +  CZONW1 )  .LE.  WZON1 

*  Y  +  CZ0NL1)  .LE.  LZON1 


An  aircraft  is  in  a  given  zone  2  if  its  position  (X,  Y,  Z)  and 
horizontal  velocity  (XD,  YD)  satisfy: 


(4)  -WZON2  .LE.  (AZONW2 

(5)  -LZON2  .LE.  (AZ0NL2 

(6)  -ZZON2  .LE.  (AZ0NZ2 

(7)  (XD  *  AZONL2  +  YD  * 

(8)  (XD  *  AZ0NL2  +  YD  * 


*  X  ♦  BZ0NW2  *  Y  +  CZ0NW2 )  .LE.  WZON2 

*  X  +  BZONL2  *  Y  +  CZ0NL2)  .LE.  LZON2 

*  X  +  BZ0NZ2  *  Y  +  CZONZ2  *  Z  +  DZ0NZ2).LE.  ZZON2 

BZ0NL2)  .LT.  0 

BZONL2)2.GE.  (XD2+YD2)  *  C0AA2 


NOTE:  AZ0NL2  and  BZONL2  are  the  east  and  north  components  of  a  normal 
horizontal  vector  parallel  to  the  main  axis  of  the  given  zone  2 
and  pointing  away  from  the  air  field. 

Each  type  2  final  approach  zone  will  have  an  externally  enterable  flag 
indicating  whether  the  given  type  2  zone  is  currently  active  or  not. 

Each  group  of  detining  parameters  for  a  zone  1  or  2  will  have  an  airport 
name  associated  with  it.  This  name  allows  zones  from  different  airports 
to  be  differentiated  in  spatial  dependent  detection  logic. 
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TABLE  7-11 


SYNOPSIS  OF  DETECT  PARAMETERS 
(Grouped  by  Invoking  Routine) 


DETECT 


ADET  92.5  sec2 

AFDET  Maximum  (ZAFCON,  AFCON ,  AF  AIFR,  AFPWI,  AFIFR) 

BDET  .107  nmi2 

DOTTH  10  nmi  *  knt 

TLA  Set  by  coarse  screen 

VMDTH  100  knt 2 

VRZTH  15  ft /min 

RDET  Maximum  (ZRCON2,  RCON2,  RCMD2,  RIFR2,  RFPWI2 , 

RFIFR2) 


SCAFLG 


AFCON 

MDCON2  • 

RCON2 

TCONH  '  , 

TCONV 

ZAFCON 

ZRCON 


Table  look-up. 

Computed  from  table  look-up  (in  PREPAR). 

275  ft 
.25  nmi2 


SCMDF 


AF 

RCMD2  | 

TCMDH  ' 

TCMDV 

ALTDP  * 

TDP 

TVDP 

TTM 


Table  look-up. 

Table  look-up  or  computed  from 
table  look-up. 

Vertical  divergence  parameters, 
from  CCMDT  or  CUMDT. 

2»  SCANS 


SIFRF 


AIFR  , 

RIFR2  , 

TIFRH 

TIFRV 

ALTDP 

TDP 

TVDP 

TTM 


Table  look-up. 

Computed  from  table  look-up. 


See  SCMDF. 
2  scans 
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TABLE  7-11 


SYNOPSIS  OF  DETECT  PARAMETERS 
(Continued) 


SFPWF 


AFPWI  1 
MDFPW2  }• 
RFPUI2  j 

TFPWIH  \ 
TFPWIV  J 


AFIFR  ] 
MDFPI2  }> 
RFIFR2  J 

TFIFRH  \ 
TFIFRV  J 


Table  look-up. 

Table  look-up  or  computed  from 
table  look-up. 

SFPIF 

Table  look-up. 

Computed  from  table  look-up. 


SPWIF 


RPMIN  4.0  nmi2 
TLPSQ  900  sec 2 
VPl  2000  ft 


A1 

B1 

Cl 

A2 

B2 

C2 

C3 

C  4 

ZMIN 

ZMAX 


Dl 

El 

FI 


» 

4 


NOI 

NOII 


SATAZ/FAZSET 


One  set  for  each  type  I  and  type  II 
area.  Site  specific. 


Allow  up  to  5  sets  for  each  area  type  I. 
Site  specific. 


Site  specific. 
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TABLE  7-11 


SYNOPSIS  OF  DETECT  PARAMETERS 
( Continued) 


SATAZ/FAZSET  (Continued) 


RDIST  83.3  nmi 


NOZ1  1 

NOZ2  J  Site  Specific 


AZONL1 

AZONW1 

BZONL1 

BZONW1 

CZONL1  ■ 

CZONW1 

LZON1 

WZON1 

ZZON1  . 


Constants,  used  in  final  approach  zone 
(FAZ)  logic.  One  set  for  each  type  1 
final  approach  zone.  Site  specific. 


AZONL2 

AZONW2 

AZONZ2 

BZONL2 

BZONW2 

BZONZ2 

CZONL2 

CZONW2 

CZONZ2 

DZONZ2 

LZ0NE2 

WZ0NE2 


One  set  for  each  type  2  final  approach 
zone.  Allow  for  20  sets.  Site  specific. 


ZZON2  “  200  ft 
COAA2  =  .9698 


SETPAR 


VRATTH  2.25 

VRATC  2.25 


7-52 


TABLE  }-ll 


ACONTH  ] 
RCONTH  V 
TWARN  J 

VRZCON 


MTTR2 

MTTA 

MTTVSQ 

COSP2 

MTTSB2 

MTTRM2 


CAMR2 

CAMA 

CAMVSQ 

CAMCP2 

MTTRM2 

CAMSB2 


SYNOPSIS  OF  DETECT  PARAMETERS 
( Concluded) 


PREPAR 


Table  look-up. 


-300  fpm 


SMTTF 


3.25  nmi2 
1000  ft 
325  knt2 
.981 
.117 

.00244  nmi.2 


CAMAN 


3.25  nmi.2 
1000  ft 
325  knt2 
.981 

.00244  nmi2 
.117 
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TABLE  7-12 


ACID1 

ACID2 

ALT 

CAFLG 

CMDFLG 

CPSID 

DOT 

ENAT 
FPIFLG 
FPWFLG 
I CAFLG 
I FRF LG 
LETID 

MD2 

MTTFLG 
PWIFLG 
RANGE 2 
TH 

TV 


LOGICAL  CONTENT  OF  AN  ENTRY  ON  AN  ENCOUNTER  LIST 

Identification  of  first  aircraft  in  pair. 

Identification  of  second  aircraft  in  pair. 

Absolute  value  of  current  altitude  separation. 

Controller  alert  for  aircraft  pair  flag. 

Resolution  advisory  for  aircraft  pair  flag. 

Identity  of  the  sector  with  which  this  encounter  is 
associated  and  processed 

Dot  product  of  relative  separation  and  relative 
velocity  vectors. 

Encounter  area  type. 

Threat  advisory  to  controlled  aircraft  flag. 

Threat  advisory  to  uncontrolled  aircraft  flag. 

Bypass  the  3-out-of-5  logic  for  controller  alert  flag. 

Resolution  advisory  to  controlled  aircraft  flag. 

List  encounter  type  identification,  indicating  the  5 
possible  encounter  lists  to  which  the  entry  belongs. 

Miss  distance  squared. 

Bypass  2-out-of-3  rule  for  resolution  advisory  flag. 
Proximity  advisory  for  aircraft  pair  flag. 

Range  squared. 

Time  until  a  horizontal  separation  threshold  (DSQ)  is 
violated. 

Time  to  coincidence  in  the  vertical  direction. 
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1.  If  a  potentially  hazardous  situation  exists,  i.e., 
should  a  Proximity  or  Threat  Advisory  Message  be  sent  to 
the  aircraft. 


2.  If  the  controller  should  know  about  the  potential 
conflict  situation. 

3.  If  an  aircraft  should  get  a  Resolution  Advisory  Message 
and  when  (it  does  not  determine  the  type  of  resolution). 

The  Detect  Task  utilizes  the  state  vectors  of  the  aircraft  pair 
from  the  Coarse  Screen  Processing  Task  to  determine  if  the  ATARS 
system  must  take  action  on  this  pair.  Action  will  be  taken  if 
an  estimate  of  the  time  to  a  separation  violation  is  below  a 
threshold  or  the  present  separation  between  aircraft  is  less 
than  a  required  minimum.  Specifically  the  primary  outputs  of 
the  task  are  the  eight  flags: 

1.  PWIFLG  -  set  if  a  proximity  advisory  is  required  for 
the  pair. 

2.  FPWFLG  -  set  if  a  threat  advisory  is  required  for 
uncontrolled  aircraft  in  the  pair. 

3.  FPIFLG  -  set  if  a  threat  advisory  is  required  for 
controlled  aircraft  in  the  pair. 

4.  CMDFLG  -  set  if,  based  on  this  cycle,  an  ATARS 
Resolution  Advisory  Message  is  requested  for  the  pair. 

This  flag  is  in  no  way  dependent  on  controlled  or 
uncontrolled  status  of  the  aircraft.  It  must  be  set  if 
there  is  a  resolution  advisory. 

5.  IFRFLG  -  set  if  a  controlled  aircraft  is  to  receive  a 
resolution  advisory.  This  flag  forces  the  setting  of 
CMDFLG. 

CMDFLG  can  be  set  without  IFRFLG  being  set,  however. 

6.  CAFLG  -  set  if  a  controller  alert  is  required  for  this 
pair. 

7.  ICAFLG  -  set  if  the  three  out  of  five  sliding  window 
logic  is  to  be  bypassed  for  controller  alerts. 

8.  MTTFLG  -  set  if  the  two  out  of  three  sliding  window 
logic  will  be  bypassed  in  the  resolution  section.  Setting 
the  MTTFLG  implies  that  the  appropriate  resolution  flag  has 
been  set. 


These  flags  are  used  during  the  resolution  phase  and  when  the 
ATARS  messages  are  built  for  output  to  the  data  link.  A  review 
of  Sections  2.2.1  through  2.2.3  will  be  helpful  in  understanding 
the  use  of  these  flags  and  in  understanding  the  Detect  Task, 
itself.  Table  7-1  details  which  flags  can  be  set  for  any  combi¬ 
nation  of  equipment  and  controlled  status  for  a  single  aircraft. 
The  flags  set  for  an  aircraft  pair,  the  output  of  detection, 
would  simply  be  the  combination  of  two  such  conditions.  Table 
7-2  lists  routines  of  the  Detect  Task  and  which  flags  each  rou¬ 
tine  can  set.  The  designation  MTT  refers  to  the  post-processing 
section  of  the  SMTTF  module  (Figure  7-2,  Page  8  of  9).  This 
section  sets  the  appropriate  flags  if  a  maneuvering  target  threat 
has  been  indicated  by  SMTTF.  Table  7-3  shows  which  routines  are 
called  for  the  particular  equipage  and  control  state  of  the  air¬ 
craft  pair.  By  combining  with  Table  7-2  one  can  determine  the 
possible  flag  settings  for  an  aircraft  pair  state. 

The  Detect  Task  bases  the  decision  on  when  to  set  flags  by 
predicting  the  time  until  minimum  separation  is  violated  in  the 
horizontal  and  vertical  dimensions.  The  horizontal  prediction 
is  designated  TH,  the  vertical,  TV.  TH  and  TV  must  be  less  than 
some  threshold  value  for  a  controller  alert,  proximity,  threat 
and  resolution  advisory  flag  to  be  set.  In  all  situations,  a 
proximity  check  is  also  performed  in  each  of  the  two  directions. 
This  allows  for  identification  of  a  hazardous  situation  even 
under  circumstances  where  the  predictions  TH,  TV  are  not  appro¬ 
priate. 

A  few  comments  concerning  the  formulae  used  in  detection  are 
pertinent . 

1.  The  modification  to  the  TH  formula  (true  horizontal  tau 
is  the  current  horizontal  separation  divided  by  the 
negative  of  the  time  derivative  of  the  current  horizontal 
separation),  DSQ,  reduces  the  value  of  TH  depending  on  the 
aircraft  velocities. 

It  allows  more  warning  time  for  faster  aircraft  closure 
than  given  by  the  unmodified  formula. 

2.  The  parameter  MD2  is  the  predicted  miss  distance  at  the 
time  of  minimum  separation.  It  is  required  that  MD2  be 
within  certain  distances  for  controller  alert  and  threat 
advisory  initiation. 

3.  The  third  page  of  the  Detect  Task  flow  chart  (Figure 
7-2)  refers  to  the  multiplicity  of  an  aircraft  pair 
(MULT).  This  is  defined  as  follows: 
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MULT 


2  if  neither  aircraft  is  in  a  conflict  table. 


=  NAC  +  1  if  only  one  aircraft  is  in  a  conflict 
table,  where  NAC  is  the  number  of  aircraft  in 
that  table. 

=  NAC  if  both  aircraft  are  in  the  same  conflict 
table. 

=  NAC(ACl)  +  NAC(AC2)  if  the  aircraft  are  in 
separate  conflict  tables. 

7.1.1  Resolution  Advisory  Initiation 

The  Detect  Task  can  be  viewed  as  having  two  main  functions, 
determining  if  the  situation  requires  a  resolution  advisory  and 
determining  if  a  controller  alert  is  warranted.  The  latter  is 
discussed  in  the  next  section. 

The  resolution  initiation  logic,  provided  by  routines  SCMDF  and 
SIFRF ,  entails  three  essential  stages:  a  horizontal  tau  check, 
with  horizontal  immediate  range  override;  a  vertical  tau  check, 
with  vertical  immediate  separation  override;  and  a  vertical 
convergence/divergence  filter.  Basically,  this  filter  inhibits 
resolution  advisory  initiation  when  an  aircraft  pair  is 
projected  to  be  at  a  vertical  separation  of  at  least  ALTDP 
(system  parameter)  within  a  period  TDP  (system  parameter)  from 
current  time.  Resolution  flags  may  also  be  set  through  the 
maneuvering  target  threat  logic  (SMTTF  Routine),  which  is 
designed  to  provide  additional  protection  to  ATARS  equipped 
aircraft  from  unequipped  aircraft,  provided  certain  flight 
geometry  requirements  are  met.  These  are  as  follows:  first,  the 
aircraft  must  be  flying  essentially  in  parallel;  and  second, 
the  target  (i.e.,  unequipped)  aircraft  must  not  be  in-trail  of 
the  subject  aircraft,  or  vice  versa.  Additionally,  the  aircraft 
must  be  within  specified  horizontal  and  vertical  separations. 

If  these  conditions  are  satisfied,  the  target  aircraft  turn 
status  is  tested  in  order  to  anticipate  a  potential  turn  into 
the  subject  aircraft.  If  so,  the  appropriate  flags  are  set,  and 
the  normal  sliding  window  logic  is  bypassed  in  the  Master 
Resolution  Task. 

The  sliding  window  logic  is  also  overridden  if  a  resolution  flag 
is  set  due  to  proximity  alone  or  the  values  of  TH  and  TV  are 
significantly  below  the  threshold  limits. 
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Besides  the  vertical  convergence/divergence  filter  there  is  an 
additional  method  for  resolution  initiation  to  be  preempted, 
through  the  zone  types.  If  both  aircraft  are  in  a  final 
approach  zone  1  or  2  (see  7.1.4),  no  resolution  advisory  flags 
are  set. 


7.1.2  Controller  Alert  Initiation 


Controller  alert  initiation  logic  resembles  the  resolution 
advisory  determination  function.  Its  purpose  is  entirely 
distinct,  however.  If  one  or  both  aircraft  are  in  a  controlled 
state,  it  is  desired  to  inform  the  controller  of  a  possible 
conflict  situation  before  a  resolution  advisory  is  necessary. 

As  such,  the  system  parameters  are  less  stringent  in  controller 
alert  routines  and  to  a  certain  extent  the  program  logic 
reflects  this. 

Controller  alert  initiation  logic,  provided  by  SCAFLG,  entails 
two  of  the  three  stages  of  resolution  advisory  logic,  tau  checks 
and  proximity  overrides.  In  addition  SCAFLG  will  set  the  CAFLG 
if  the  aircraft  are  parallel,  offset,  within  specified 
horizontal  and  vertical  separations  and  one  aircraft  is  turning 
towards  the  other  (see  CAMAN).  In  this  case  and  in  the  case  of 
proximity  overrides  the  sliding  window  logic  is  bypassed,  i.e., 
ICAFLG  is  set. 

Preemption  of  controller  alert  occurs  if  the  aircraft  are  in  an 
encounter  area  type  (ENAT)  1  or  2,  which  does  not  require  a 
controller  alert,  or  are  both  in  an  active  zone.  Regional 
dependent  processing  is  discussed  in  Section  7.1.4. 

7.1.3  Parameter  Selection 


The  majority  of  the  various  thresholds  that  appear  in  the  Detect 
Task  and  its  routines  depend  on  a  number  of  criteria  for  their 
determination.  Those  parameters  (or  thresholds)  that  are  not 
true  constants  are  in  general  assigned  in  the  routine  SETPAR. 
First,  the  non-constant  thresholds  may  depend  on  the  control 
status  of  the  aircraft  in  an  encounter:  cont rol led/cont rol led , 
controlled/  uncontrolled,  or  uncontrolled/uncontrolled.  Add¬ 
itional  specification  may  depend  on  area  type  of  the  encounter 
(1,  2,  3,  4),  multiplicity  of  the  encounter,  and  ATARS 
equipage.  In  the  case  of  uncont rol led /uncont rol led  encounters, 
specification  may  also  rely  on  a  computed  index,  UUIND,  which  is 
set  in  the  routine  SETPAR.  Furthermore,  certain  tau  thresholds 
are  computed  based  on  closing  speed,  and  ultimately  rely  on  the 
thresholds  TCONV  and  TCONH  provided  by  the  routine  PREPAR.  A 
synopsis  of  all  detection  parameters  may  be  found  in  Table  7-11, 
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together  with  an  indication  of  the  specification  mode,  be  it  a 
true  constant  (in  which  case  the  nominal  parameter  value  is 
entered),  a  table  look-up,  or  computed  based  on  table  look-up 
values. 

Notes  on  the  tables  follow. 

Table  7-4  -  contains  parameters  used  in  routine  PREPAR  to 
calculate  TCONH  and  TCONV.  These  are  the  tau  thresholds  in  the 
horizontal  and  vertical  sense  which  determine  the  look-ahead 
times  for  a  controller  alert.  TCONH  and  TCONV  are  in  turn  used 
in  SETPAR  to  calculate  resolution  and  threat  advisory  message 
look-ahead  time.  In  this  way  the  controller  is  guaranteed 
knowledge  of  a  possible  aircraft  conflict  before  or  at  worst 
simultaneously  with  ATARS  display  posting.  Note  that  the 
desired  threshold  time,  TWARN,  is  modified  so  that  the  time 
until  separation  criteria  (ACONTH,  RCONTH)  are  violated  is 
represented  and  not  the  time  until  collision. 

Table  7-5  -  defines  the  proximity  thresholds  (as  opposed  to  tau 
thresholds)  which  when  violated  will  generate  a  controller 
alert.  Desensitization  of  the  ATARS  detection  logic  occurs  as 
these  distances  decrease  for  the  smaller  numbered  area  and  zone 
type.  MDC0N2  is  the  threshold  for  predicted  minimum  miss  dis¬ 
tance,  RC0N2  and  AFCON  the  thresholds  for  the  present  separation 
in  each  dimension. 

Tables  7-6  through  7-8  -  define  the  tau  thresholds  and  immediate 
proximity  thresholds  for  resolution  advisory  and  threat  advisory 
conditions.  The  intention  is  to  guarantee  (if  time  permits)  the 
sequence  of  events  as  explained  in  Sections  2.2.1  -  2.2.3.  For 
example,  one  aircraft  is  uncontrolled,  the  other  controlled, 
both  equipped.  The  threat  advisory  to  both  aircraft  and  the 
controller  alert  are  posted  at  the  same  time,  since  the  delay 
from  controller  alert  time  (the  column  labeled  S)  is  0  (zero) 
for  TFPWI,  TFIFR  parameters.  A  resolution  advisory  to  the 
uncontrolled  aircraft  occurs  15  seconds  after  controller  alert 
(S  column  for  TCMD  parameter)  and  if  no  change  in  the  situation 
occurs  the  resolution  advisory  to  the  controlled  aircraft  occurs 
20  seconds  later  (S  under  TIFR  parameter  column).  Of  course  the 
initiation  times  cannot  be  too  large  or  small,  hence  the  L  and  U 
columns. 

The  tabular  settings  can  be  modified  under  one  condition  -  there 
is  no  delay  giving  a  controlled  aircraft  resolution  advisories 
if  there  is  a  large  speed  differential  compared  to  the  uncon¬ 
trolled  aircraft.  The  system  parameter  VRATC  determines  this 
cond i t i on . 
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Table  7-9  -  defines  the  parameters  used  in  the  vertical 
divergence  logic  present  in  those  routines  which  set  a 
resolution  advisory  flag.  Two  sets  of  parameters  exist,  both 
aircraft  uncontrolled  (UCMDT)or  at  least  one  aircraft  controlled 
(CCMDT).  If  the  time  to  minimum  separation  violation  is  TVDP 
seconds,  then  the  logic  is  applied.  For  aircraft  more  than 
ALTDP  feet  apart  after  TDP  seconds,  no  resolution  advisory  flag 
is  set. 


7.1.4  Area  Type  and  Zone  Determination 

As  indicated  previously,  selection  of  thresholds  may  depend  on 
the  area  type  of  an  encounter,  ENAT,  determined  in  the  routine 
SENAT.  The  encounter  aria  type  depends,  in  turn,  on  the 
individual  aircraft  area  types,  ACAT,  which  are  determined  in 
the  SATAZ  routine.  This  provides  a  means  for  desensitizing 
logic  thresholds,  with  ENAT  4  being  the  most  sensitive  area, 

ENAT  1  being  the  least  sensitive.  Each  ACAT  area  type  1  or  2 
defines  a  horizontal  parallelogram,  type  1  encompassing  the 
immediate  vicinity  of  an  airfield,  and  type  2  approach  areas  for 
each  runway  between  specified  altitudes.  Area  type  1  may,  how¬ 
ever,  be  further  modified  with  "legs",  or  straight  line  segments 
that  may  be  used  to  remove  corners  of  the  parallelogram.  Type  3 
is  the  balance  of  the  airspace  out  to  a  range  of  RDIST  (system 
parameter),  beyond  which  the  area  type  is  4  (see  Table  7-10). 
SENAT  defines  the  mapping  of  individual  aircraft  area  types  into 
the  encounter  area  type. 

The  final  approach  zone  status  of  arriving  aircraft,  FAZ, 
contained  in  the  state  vector  is  utilized  in  the  Detect  Task, 
the  Terrain/  Airspace/Obstacle  Avoidance  Task  as  well  as  in  the 
Master  Resolution  Task.  Basically,  the  final  approach  zone  is 
divided  into  two  types,  type  1  encompassing  the  airfield  (and 
generally  to  a  lower  altitude  than  for  area  type  l),  and  type  2 
encompassing  a  sloping  rectangular  region  containing  the  normal 
approach  path  for  each  runway.  In  the  type  2  zones,  a  table  of 
active  flags  indicates  the  current  status  of  each  final  approach 
zone  2. 

The  parameter  FAZ  can  have  the  following  values  upon  entry  into 
the  Detect  Task. 

FAZ  =  -l,  not  intialized  for  this  aircraft, 
must  be  set  by  Detect  Task 

FAZ  =  0,  aircraft  is  not  in  a  final  approach  zone 

FAZ  =  1,  aircraft  is  in  a  final  approach  zone  1 
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FAZ  ■  2,  aircraft  is  in  a  final  approach  zone  2 


The  routine  FAZSET,  called  when  FAZ  is  not  initialized,  is  the 
SAme  routine  used  in  the  Terrain/Airspace/Obstacle  Avoidance 
Task.  If  FAZ  has  the  value  1  or  2  then  the  state  vector 
parameter  ZPRT  has  been  initialized  to  the  call  letters  of  the 
airport  associated  with  the  final  approach  zone. 

The  area  types  define  the  area  of  desensitization  for  the 
controller  alert  function,  the  zones  define  the  area  for 
desensitization  for  the  resolution  advisory  function.  However, 
there  is  one  important  exception  -  zone  2.  This  region  also 
defines  where  controller  alerts  generated  by  prediction  (tau 
tests)  are  to  be  inhibited.  The  proximity  tests  are  never 
inhibited.  Appropriate  definition  of  this  area  will  prevent 
nuisance  alerts  in  parallel  approach  zones  and  converging 
approach  zones.  Zone  2  should  always  be  encompassed  by  area 
type  1  and/or  2.  For  the  prevention  function  to  be  applicable 
both  aircraft  must  be  in  a  zone  2  region  (not  necessarily  the 
same)  associated  with  the  same  airport. 

7.1.5  Detect/Executive  Interface 


The  detection  logic  requires  the  following  parameters  from  both 
of  the  state  vectors  associated  with  the  aircraft  pair:  X,  Y,  Z 
XD,  YD,  ZD,  VSQ,  TURN,  CTPTR.  If  available  in  the  state  vector 
the  Detect  Task  will  use  FAZ  and  ZPRT.  If  not  available  detect 
will  determine  FAZ  and  ZPRT,  inserting  them  into  the  state 
vector.  From  the  conflict  table,  if  it  exists  (CTPTR  not  null) 
detect  requires  NAC,  BIC.  From  the  Coarse  Screen  Processing 
Task,  the  parameter,  TLA,  is  required.  It  is  the  executive 
program's  responsibility  to  assemble  these  needed  variables  and 
guarantee  their  existence  upon  calling  the  Detect  Task. 

On  completion  of  the  Detect  Task  all  eight  flags  have  been 
initialized  and  appropriately  set:  PWIFLG,  FPWFLG,  FPIFLG, 
CMDFLG,  IFRFLG,  CAFLG,  ICAFLG,  MTTFLG.  If  the  flags  indicate 
any  type  of  ATARS  advisory  message  is  to  be  posted  or  a 
controller  alert  is  required,  then  the  Detect  Task  also 
guarantees  a  value  for  ALT,  DOT,  ENAT,  MD2,  RANGE2,  TCMDV, 
TCMDH,  TH,  TV. 

It  is  the  executive  program’s  function  to  disburse  the  Detect 
Task  output  as  necessary.  Specifically: 

1.  No  resolution  advisories  (CMDFLG,  IFRFLG  not  set)  but 

proximity  and/or  threat  advisories  are  required  (PWIFLG, 
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FPWFLG,  FPIFLG  set),  an  entry  is  created  for  the  Proximity 
Encounter  List.  A  controller  alert  may  or  may  not  be 
required.  Number  3  below  may  also  apply. 

2.  A  resolution  advisory  (CMDFLG  or  IFRFLG  set)  or  a 
controller  alert  (CAFLG  or  ICAFLG  set)  is  required,  an 
entry  is  created  from  the  Detect  Task  output  and  placed  on 
the  Resolution  Encounter  List. 

3.  CMDFLG  and  IFRFLG  flags  zero  and  a  conflict  pair  record 
exists  for  the  aircraft,  an  entry  is  placed  on  the 
Resolution  Deletion  Encounter  List. 

4.  All  flags  zero  and  no  conflict  pair  record  exists,  no 
action  is  taken. 

Besides  the  three  encounter  lists  mentioned,  there  are  the 
Delayed  Resolution  Encounter  List  and  the  Normal  Resolution 
Encounter  List.  Both  of  these  lists  are  formed  by  the  Seam  Pair 
Task  from  the  Resolution  Advisory  List  as  generated  by  the 
Detect  Task.  The  entry  format  is  standard  for  all  five  lists. 
Table  7-12  defines  this  entry  structure. 

7.2  Seam  Pair  Task 


This  task  selects  the  correct  disposition  of  each  pair  found  on 
the  Resolution  Encounter  List.  Such  pairs  either  have  CMDFLG 
set,  with  other  flags  in  any  condition,  or  have  only  CAFLG  set 
(and  not  CMDFLG,  FPWFLG,  FPIFLG,  or  PWIFLG) .  The  Seam  Pair  Task 
(Figure  7-16)  classifies  each  pair  in  one  of  four  groups: 

1.  Pairs  already  being  resolved  by  another  ATARS  site. 

2.  Pairs  previously  resolved  by  another  ATARS  site,  but 
now  in  "handoff"  condition.  (Caution:  This  term  refers 
only  to  ATARS  responsibility  and  has  nothing  to  do  with  ATC 
control  or  ATC  handoff.) 

3.  Pairs  already  being  resolved  by  own-site. 

4.  Pairs  not  yet  being  resolved. 

If  a  pair  falls  into  group  (2)  or  (4),  a  priority  test  is 
performed  to  determine  own-site's  eligibility  to  resolve  the 
pair.  When  one  or  both  aircraft  are  ATCRBS,  own-site  assumes  it 
has  priority.  If  both  are  DABS,  then  own-site  has  priority  if 
own  ATARS  site  ID  bit  is  the  highest  bit  appearing  in  both  GE0G1 
and  GE0G2 . 
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If  own-site  does  not  have  priority  in  groups  (2)  and  (4)  or 
the  pair  is  in  group  (1),  the  pair  is  put  onto  the  proximity 
encounter  list  (except  when  only  CAFLG  was  set)  for  traffic 
advisory  processing.  This  service  may  be  permitted,  even  if 
own-site  does  not  have  resolution  responsibility  for  this  pair. 

The  remainder  of  the  task  is  performed  when  own-site  has 
priority,  or  was  already  resolving  the  pair.  If  CAFLG  is  set, 
the  pair  is  placed  on  the  controller  alert  buffer.  Ii  CMDFLG  is 
not  set,  or  if  the  pair  is  ATCRBS-ATCRBS ,  resolution  will  not  be 
performed. 

If  a  pair  record  already  exists,  the  PWISF  flag  is  set  to 
inhibit  pair  removal  (Section  13.)  since  this  pair  is  receiving 
resolution  processing  this  scan.  The  pair  record  sector  identi¬ 
fication  is  updated  here.  If  ATSID  indicated  a  "handoff"  (group 
2)  own  ID  is  put  into  ATSID.  For  groups  (2)  and  (4),  a  message 
is  sent  to  any  adjacent  sites  also  providing  service  to  either 
aircraft.  This  message  announces  that  own-site  is  resolving 
this  pair.  It  should  be  sent  promptly  since  ATCRBS-DABS  pairs 
are  assigned  to  sites  in  a  first-come  first-serve  manner.  At 
this  point  it  is  necessary  to  decide  whether  resolution 
processing  can  proceed  immediately,  or  whether  the  resolution 
processing  must  be  delayed  until  conflict  tables  have  been 
received  from  adjacent  ATARS  sites.  Resolution  of  a  pair  of 
aircraft  which  could  in  any  way  be  influenced  by  actions  taken 
by  neighboring  ATARS  sites  must  be  delayed  until  replies  are 
received  from  all  neighboring  ATARS  sites  serving  either 
aircraft.  In  no  case  does  this  delay  extend  beyond  a  cutoff 
time  determined  by  the  executive. 

Resolution  is  delayed  if: 

1.  The  pair  is  already  represented  in  a  seam  conflict 

table  and  the  local  ATARS  is  responsible  for  that  pair,  or 

2.  the  pair  was  not  previously  in  conflict  but  at  least 

one  of  the  aircraft  is  in  an  ATARS  seam  or  is  in  a  seam 

conflict  table. 

In  these  situations,  the  pair  is  placed  on  the  Delayed  Resolution 
List;  otherwise,  the  pair  is  placed  on  the  Normal  Resolution 
List. 


8. 


DATA  LINK  MESSAGE  PRE-PROCESSING  TASK 


The  Data  Link  Message  Pre-processing  Task  creates,  updates,  and 
deletes  entries  on  a  list  maintained  for  each  subject  aircraft 
in  a  conflict.  This  list,  called  the  Proximity  Warning  Indi¬ 
cator  List  (PWILST)  is  linked  to  the  state  vector  of  the  subject 
aircraft  and  contains  all  data  on  aircraft  which  are  in  conflict 
with  the  subject  aircraft.  This  list  is  initialized  for  the 
conflict,  is  updated  during  the  conflict  either  by  addition  of  a 
new  aircraft  or  a  change  in  the  conflict  status,  and  is  deleted 
when  the  subject  aircraft  is  no  longer  in  conflict  or  has  left 
the  ATARS  service  area.  This  list  is  processed  by  the  Data  Link 
Message  Construction  Task  (discussed  in  Section  14)  to  generate 
Proximity,  Threat,  or  Resolution  Advisory  Messages  for  the 
subject  aircraft. 

8.1  PWILST  List  Structure 


Each  object  aircraft  in  conflict  with  the  subject  aircraft  has 
entries  on  the  list.  Each  entry  contains  a  header  segment 
followed  by  a  varying  length  message  segment.  Figure  8-1 
diagrams  a  portion  of  the  subject  aircraft  state  vector,  the 
conflict  table,  pair  record  and  the  PWILST.  Figure  8-2  shows 
further  details  of  the  PWILST  structure.  Page  1  of  Figure  8-2 
shows  each  field  in  the  PWILST  header.  The  header  fields  are 
used  internally  by  programs  that  process  the  PWILST.  Page  2  of 
Figure  8-2  shows  the  types  of  message  segments  that  may  follow 
the  header  segment.  Each  segment  is  named  by  encounter 
(conflict)  type.  A  Proximity  Segment  contains  data  that  is 
generated  for  an  encounter  which  is  at  the  warning  level.  A 
Threat  Segment  contains  data  generated  for  an  encounter  at  the 
threatening  level,  and  a  Resolution  Segment  contains  data 
generated  for  an  encounter  which  is  very  serious  and  requires 
resolution. 

8.2  PWILST  Message  Data 

The  Proximity  Segment,  shown  diagranmed  in  Figure  8-3,  contains 
three  types  of  data:  position  data,  start/end  data,  and  supple¬ 
mentary  proximate  data.  Tables  8-1  through  8-9  provide  further 
details  on  each  type  of  data  required  in  the  Proximity  Segment. 

Four  types  of  data  are  required  in  the  Threat  Segment  shown 
diagrammed  in  Figure  8-4:  basic  threat  data,  position  data, 
start  threat  data,  and  end  data.  Tables  8-10  through  8-14 
provide  further  details  on  each  new  type  of  data  required  in  the 
Threat  Segment. 
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TABLE  8-1 


POSITION  DATA 


FIELD  BITS 


INTERPRETATION 


Clock  Bearing  (CB)  4 

Fine  Bearing  (FB)  3 

Altitude  Zone  2 


Relative  3 

Altitude  (RA) 

Range  ( R)  6 

Coarse  Heading  3 

(CH) 

ATC  Control  1 

ATARS  Equipped  1 

Most  Critical  Flag  1 


1  o'clock  (0001)  through  12  o'clock  (1100) 

Bearing  to  target  = 

((CB)  -  1/2)  *  30o  +  (FB)  *  3.750 

Bit  1:  proximate  or  threat  aircraft 
above  (1)  or  below  (0) 

Bit  2:  proximate  or  threat  aircraft 
co-altitude  (1)  or  not  (0) 

If  co-altitude  (0  to  500'):  =  (RA)  *  100'. 
If  not  co-altitude  (600'  to  2000'): 

=  (RA)  *  200'  +  600’ 

0  to  12.6  nmi  =  (R)  *  0.2  nrai . 

It  .GE.  12.6  display  12.6 

N(000),  NE(001),  E(010) ,  SE(011)  etc. 

(.See  Table  8-7  for  Fine  Heading) 

Controlled  (1),  uncontrolled  (0) 

ATARS  equipped  (1)  or  not  (0) 

Most  critical  advisorv  (1)  or  not  (0) 


TOTAL 


24 


TABLE  8-2 


SOURCE  OF  POSITION  DATA 


FIELD 


Clock  Bearing  (CB) 

Fine  Bearing  (FB) 
Altitude  Zone 
Relative  Altitude  (RA) 
Range  (R) 

Coarse  Heading  (CH) 

ATC  Control 
ATARS  Equipped 
Most  Critical  Flag 


SOURCE 

Table  8-3,  Equation  I 

Table  8-3,  Equation  II 

Table  8-3,  Equation  III 

Table  8-3,  Equation  IV 

Table  8-3,  Equation  V 

Table  8-3,  Equation  VI 

State  Vector 

State  Vector 

Figure  14-4,  Compute 
Criticality  Routine 


TABLE  8-3 


POSITION  DATA  FIELDS 


Notes  for  Table  8-3  through  Table  8-23: 

1.  All  angles  expressed  in  degrees. 

2.  Logic  expressions  equal  1  if  true,  0  if  false. 

3.  INT  (  )  is  the  integer  part  function.  This  is  rounded  (except  where  noted)  by 
adding  .5  before  taking  the  integer  part. 

4.  State  vector  variables  ending  in  1  apply  to  own  aircraft,  those  ending  in  2 
apply  to  other  aircraft. 

5.  XI,  Y1  Position  of  aircraft  1 

6.  XD1,  YD1  Velocity  of  aircraft  1 


BEARING  =  ARC  COS  (A/SQRT  ( (RANGE2)*(XD12  +  YD12)))  Correct  for  proper  quadrant. 
RX  =  X2  -  XI  A  =  RX*XD 1  +  RY*YDl 

RY  =  Y2  -  Y1  RANGE 2  =  RX2  +  RY2 


I  Clock  Bearing  (CB)  =  INT  ( (BEARING)/30) 

Change  CB  =  0  to  CB  =  12  (See  Table  8-4  for  Clock  Bearing 
corresponding  to  bearing  angles) 

II  Fine  Bearing  (FB)  =  INT  ((BEARING  -  (CB  -  1/2)  *  3Qo)/3.75°) 


Note:  tnis  value  i3  a  positive  increment  to  the  low  end  of  CB  sector. 

III  Altitude  Zone:  Bit  1  =  SIGN  ( RZ )  RZ  =  Z2  -  Z1  SIGN  (RZ)“1  if  RZ  .GE.  0) 

Bit  2  =  ABS(RZ)  .LE.  PWIZ  SIGN  (RZ)-O  if  RZ  .LT.  0) 

IV  Relative  Altitude  (RA)  =  INT  ((ABS(RZ)  .LE.  PWIZ)  *  ABS(RZ)/100  (ft) 

+  (ABS(RZ)  .GT.  PWIZ)  *  ( ABS(RZ)-600 ) /200  (ft)) 

V  Range  (R)  *  INT(  SQRT  (RX2  +  RY2  +  RZ2)/0.2  (ntni)) 

VI  Coarse  Heading  (CH)  =  INT  ( (HEADING) /45 ) 

HEADING  “  ARC  COT  (YD2/XD2)  Correct  for  proper  quadrant. 

Change  CH  *=  8  to  CH  '  0 

VII  ATC  Control  =  CUNC2 

VIII  ATARS  Equipped  =  ATSEQ2 
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TABLE  8-4 


CLOCK  BEARING 


Let  phi  be  the  bearing  of  aircraft  2  from  aircraft  1  measured 
positive  clockwise  from  the  track  heading  of  aircraft  1  and 
expressed  as  an  angle  between  0  and  360°.  Then  the  clock  bearing 
is : 


LOWER  LIMIT  .LE.  PHI  (DEGREES) 

.LT.  UPPER  LIMIT  CLOCK  BEARING 


345 

- 

15 

12 

15 

- 

45 

1 

45 

- 

75 

2 

75 

- 

105 

3 

105 

- 

135 

4 

135 

- 

165 

5 

165 

- 

195 

6 

195 

- 

225 

7 

225 

- 

255 

8 

255 

- 

285 

9 

285 

- 

315 

10 

315 

- 

345 

11 

J 


TABLE  8-5 


START/ END  DATA 


FIELD 

BITS 

INTERPRETATION 

Sensor 

Termination 

1 

Sensor  reporting  encounter  terminated 
or  not  (0) 

Velocity  (V) 

7 

0  to  1,270  kts  =  (V)  *  10  kts 

Track  Number 

3 

0  through  7 

Aircraft 

Abbreviated 

Data 

13 

Currently  undefined 

TOTAL 

24 

TABLE  8-6 


FIELD 

Sensor  Termination 
Velocity  (V) 

Track  No. 

Aircraft  Abbreviated 


SOURCE  OF  START/END  DATA 

SOURCE 

Compute  Own/End  Data  Routine 
Table  8-9,  Equation  II 
Compute  Criticality  Routine 
Data  ATC  Computer 


TABLE  8-7 


SUPPLEMENTARY  PROXIMATE  DATA 


FIELD 

BITS 

INTERPRETATION 

Track  Number 

3 

0  through  7 

Fine  Heading  (FH) 

4 

Heading  =  ( ( CH)  -  1/2)  *  45°  + 

(FH)  *  2.81250  Note:  (CH  is 

contained  in  position  data) 

Velocity  (V) 

7 

0  to  1,270  kts  «  (V)  *  10  kts 

Turn  Type  of 
of  Threat 

3 

Bit  1:  straight  (0)  or  turn  (1); 

Bit  2:  right  (1)  or  left  (0)  and 

Bit  3:  strong  (1)  or  weak  (0) 

Vertical  Speed 
of  Threat  (VS) 

6 

0  to  6200  fpm  =  (VS)  *  200  fpm 
(Signed  two's  complement  with  positive 
upward ) 

Spare 

1 

Set  =  0 

TOTAL 

24 
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TABLE  8-8 


SOURCE  OF  SUPPLEMENTARY  PROXIMATE  DATA 


FIELD 

Track  Number 

Fine  Heading  (FH) 

Velocity  (V) 

Turn  Type  of  Threat 
Vertical  Speed  of  Threat  (VS) 


SOURCE 
Figure  14-4, 

Compute  Criticality  Rout 

Table  8-9,  Equation  I 
Table  8-3,  Equation  VI 

Table  8-9,  Equation  II 

Table  8-9,  Equation  III 

Table  8-9,  Equation  IV 
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TABLE  8-9 


SUPPLEMENTARY  PROXIMATE  DATA  FIELDS 


I  Fine  Heading  =  INT  ((HEADING  -  (CH  -  l/2)*45°)/2.8125°) 

II  Velocity  (V)  =  INT  (SQRT  (VSQ2)/10  kts) 

III  Turn  Type  -  see  table  below 


IV 


TURN  VALUE 

TURN 

TYPE 

FIELD 

Strong  left 

-2 

1 

0 

1 

Weak  left 

-1 

1 

0 

0 

Strong  right 

+  2 

1 

1 

1 

Weak  right 

+  1 

1 

1 

0 

All  other 

0 

0 

0 

Vertical  Speed 

(VS)  =  INT  (ZD2/200) 

Note:  ZD2  in 

ft /min 
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r 

-  •  • 

TABLE  8-10 

BASIC  THREAT  DATA 

FIELD 

BITS 

INTERPRETATION 

Predicted  Horizontal  Miss 
Distance  (PMD) 

3 

0  to  1.4  nmi  =  (PMD)  *  0.2  nmi 

Vertical  Speed  of  Threat 
(VS) 

6 

0  to  6,200  fpm  =  (VS)  *  200  fpm  (two's  1 

complement  with  positive  upward)  ! 

Relative  Altitude  Extension 
(RAE) 

(Note:  RAE  =  0  if 

RA  .LE.  2000  ft) 

3 

0  to  3500'  =  (RAE)  *  500'  \ 

(Note:  total  relative  altitude  *  relative  j 

altitude  (from  position  data)  +  1 

relative  altitude  extension;  therefore, 

RAE  =  111  implies  total  relative  altitude 

•GE.  5250')  i 

Fine  Heading  (FH) 

4 

Heading  =  ((CH)  -  1/2)  *  45°  +  (FH)  *  j 
2.8125°  (Note:  CH  is  contained  in  ■ 
position  data)  1 

Turn  Type  of  Threat 

3 

i 

Bit  1:  straight  (0)  or  turn  (1);  f 
Bit  2:  right  (1)  or  left  (0);  1 
Bit  3:  strong  (1)  or  weak  (0)  i 

Track  No 

3 

j 

0  through  7  \ 

First  Time  Threat  Data 
Transmitted 

1 

First  time  (1)  or  not  (0). 

Set  =  1  if  Start  Threat  to  Threat  transition.  i 

Set  =  1  if  1st  Time  Threat  to  Threat  update 
and  1st  Time  Threat  not  delivered  j 

successfully.  j 

Set  =  0  otherwise  | 

Resolution  Bit 

1 

Threat  aircraft  is  receiving  resolution  1 

advisory  (1)  or  not  (0)  from  an  ATARS  site  1 

(shown  by  ATSID  in  the  pair  record  *  local 

site  ID,  other  ATARS  site  ID,  or  handoff 

and  a  maneuver  exists  in  the  pair  record 

for  the  threat  aircraft) 

TOTAL 

24 

| 

L  ...  _ 

TABLE  8-11 


SOURCE  OF  BASIC  THREAT  DATA 


FIELD 


SOURCE 


Predicted  Horizontal  Miss 
Distance  (PMD) 

Vertical  Speed  of  Threat 
(VS) 

Relative  Altitude  Extension 
(RAE) 

Fine  Heading  (FH) 

Turn  Type  of  Threat 
Track  No 

First  Time  Threat  Data 
Transmitted 

Resolution  Bit 


Table  8-12,  Equation  I 

Table  8-12,  Equation  II 

Table  8-12,  Equation  III 
Table  8-3,  Equation  IV 

Table  8-9,  Equation  I 
Table  8-3,  Equation  VI 

Table  8-12,  Equation  V 

Compute  Criticality  Routine 

Data  Link  Message  Pre-processing 
Task 

Data  Link  Message  Pre-processing 
Task 
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TABLE  8-12 


BASIC  THREAT  DATA  FIELDS 

RX  *  X2  -  XI  DOT  -  RX*VRX  +  RY*VRY 

RY  =  Y2  -  Y1  VRX  -  XD2  -  XD1 

RANGE2  *  RX2  +  RY2  VRY  *  YD2  -  YD1 

VR2  -  VRX2  +  VRY2 

If  VR2  .LT.  VMDTH  then  MD2  =  RANGE 2 

IF  VR2  .GE.  VMDTH  the  MD2  =  (RX*VRY  -  RY*VRX)2/VR2 

I  Predicted  Horizontal  Miss  Distance 

=  INT  (SQRT  (RANGE2)/0.2  nrai )  (if  DOT  .GE.  0) 

=  INT  (SQRT  (MD2)/0.2nmi)  (if  DOT  .LT.  0) 

II  Vertical  Speed  (VS)  =■  INT  (ZD2/200)  Note:  ZD2  in  ft/min 

III  Relative  Altitude  Extension  (RAE)  used  only  i f  RA  .GT.  2000  ft 
=INT  (ABS  (RZ  -  2000  ft)  /500  ft)(if  RA  .LE.  2000  ft,  RAE  -  0) 

IV  Fine  Heading  (FH)  -  Same  as  supplementary  proximate  data. 

V  Turn  Type  of  Threat  -  see  table  below 


TURN  VALUE 

TURN 

TYPE 

FIELD 

Strong  left 

-2 

1 

0 

1 

Weak  left 

-1 

1 

0 

0 

Strong  right 

+  2 

1 

1 

1 

Weak  right 

+  1 

1 

1 

0 

All  other 

0 

0 

0 
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TABLE  8-13 


START  THREAT  DATA 

FIELD 

Continuation 

Velocity  (V) 

Track  No. 

Aircraft  Abbreviated  Data 

TOTAL  24 


BITS  INTERPRETATION 

1  (1)  Track  number  exists 

(0)  New  track  number 

7  0  to  1,270  kts  =  (V)  *  10 

3  0  through  7 

13  Get  =  0 
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TABLE  8-14 


SOURCE  OF  START  THREAT  DATA 


FIELD 

Continuation 
Velocity  (V) 

Track  No. 

Aircraft  Abbreviated  Data 


SOURCE 

Compute  Criticality  Routine 
Table  8-9,  Equation  II 
Compute  Criticality  Routine 
ATC  Computer 


m 


The  Resolution  Segment  is  shown  in  Figure  8-5.  This  segment 
contains  either  DABS  resolution  data  or  ATCRBS  resolution  data 
and  ATCRBS  track  block  data.  This  is  the  only  segment  type 
which  does  not  require  all  the  data  types  shown  in  the  segment 
diagram.  Tables  8-15  through  8-23  describe  the  resolution  data 
in  further  detail. 

8.3  PWILST  Management 

The  Data  Link  Message  Pre-processing  Task  manages  the  PWILST  by 
determining  the  current  encounter  type,  searching  the  subject 
aircraft's  PWILST  for  an  entry  which  is  keyed  by  the  object 
aircraft's  identification  number,  and  performing  standard  ini¬ 
tialization,  update  or  deletion  for  the  PWILST  entries.  Figure 
8-6  shows  an  example  of  PWILST  management  where  the  subject 
aircraft  is  in  an  encounter  with  several  aircraft  and  the  program 
is  currently  searching  for  entry  "A". 

8.3.1  Encounter  Type  Determination 

The  encounter  type  is  determined  first  from  the  status  of  flags 
and  second  from  site  priority  and  DABS  sensor  status.  When  flag 
settings  determine  that  the  encounter  is  a  resolution  type  and 
the  site  has  priority,  a  Resolution  Segment  is  generated.  When 
flag  settings  determine  that  the  encounter  is  at  the  threat  or 
warning  level  and  the  sensor  is  primary,  Threat  or  Proximity 
Segments  are  generated. 

When  an  encounter  is  within  the  site  boundary  where  ATARS  pro¬ 
vides  full  resolution  services,  the  site  has  priority  and  the 
sensor  is  primary.  In  this  area,  all  segment  types  may  be  gen¬ 
erated  to  provide  all  ATARS  messages.  Outside  thi^  boundary 
where  overlapping  coverage  from  several  sites  creates  a  seam, 
some  ATARS  messages  are  suppressed  and  the  segment  types 
supporting  these  messages  are  not  created  or,  if  they  already 
exist,  they  are  deleted.  After  the  flag  status,  site  priority, 
and  sensor  status  is  determined,  six  encounter  types  for  new 
encounters  may  exist. 

1.  Encounter  type  "TR"  (threat  and  resolution)  means  that 
the  appropriate  conditions  exist  for  generation  of  a  Threat 
Segment  and  a  Resolution  Segment. 

2.  Encounter  type  "R"  (resolution  only)  means  that  a  "TR" 
encounter  type  would  normally  exist,  but  since  the  sensor 
is  not  primary,  the  Threat  Segment  of  the  normal  threat/ 
resolution  pair  is  suppressed. 
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FIGURE  8-5 

PWILST  RESOLUTION  SEGMENT 
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TABLE  8-15 


DABS  RESOLUTION  DATA 


FIELD 

BITS 

INTERPRETATION 

DABS  ID 

24 

DABS  ID 

Resolution  Advisory 

10 

(See  Figure  8-17) 

VSL  Value 

2 

(See  Figure  8-17) 

First  Time  Transmitted 

1 

First  time  (1)  or  not  (0). 
Set  “  1  if  new  resolution 
advisory  (STFLG  set). 

Set  »  1  if  update  and  new 
resolution  advisory  ,NE. 
last  successfully  deli¬ 
vered  resolution  advisory. 
Set  to  0  otherwise 

Track  # 

3 

0  through  7 

Track  #  Unknown 

1 

Set  =*  1  when  no  track  # 
exists  in  the  conflict 
table  indicating  that 
multi-site  coordination 
has  not  occurred  over 
ground  lines. 

Set  ■  0  otherwise 

Handoff 

1 

Set  *  handoff  bit  in  ATSID 
indicating  that  aircraft 
has  left  ATARS  coverage 
zone 

Spares 

6 

(Set  -  0) 

TOTAL 


48 


TABLE  8-16 


SOURCE  OF  DABS 

FIELD 

DABS  ID 

Resolution  Advisory 
VSL  Value 

First  Time  Transmitted 

Track  #  and  Track  # 

Unknown 

Handoff  Bit 


RESOLUTION  DATA 

SOURCE 
State  Vector 

Conflict  Table  and  Table  8-17 

Conflict  Table  and  Table  8-17 

Data  Link  Message  Pre-processing 
Task 

Compute  Criticality  Routine 
Pair  Record  (ATSID) 
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TABLE  8-17 


CODING  FOR  RESOLUTION  ADVISORY  AND  VSL  DATA  FIELD 


BIT# 


RESOLUTION  ADVISORY  FIELD 


1  0  *  No  horizontal  maneuver 

2  0  *  Horizontal  is  positive 

3  0  *  Sense  is  turn  left  or 

don't  turn  right 

4  0  *  No  vertical  maneuver 

5  0  "  Vertical  is  positive 

6  0  »  Negative 

7  0s  Sense  is  climb  or  don't 

descend 

8  0  *  Single  threat 

9  0  ■  Normal  condition 

10  0  *  Maneuver  for  display 


1  *  Horizontal  maneuver 

1  ”  Horizontal  is  negative 

1  =  Sense  is  turn  right  or 
don't  turn  left 

1  =  Vertical  maneuver 

1  *  Vertical  is  negative  or 
VSL  according  to  bit  6 

1  **  VSL 

1  ■  Sense  is  descend  or  don't 
climb 

1  *  Multiple  threats  (MT  bit) 

1  ■  Coordination  failed  (FAIL 
bit) 

1  *  Complement  flag;  no  display 


BIT  #  VSL  FIELD 

_ (APPLIES  WHEN  BIT  6  ABOVE  »  1) 


1  0  ■  Limit  to  500  ft/min  1  *  Bit  2  determines 

2  0s  Limit  to  1000  ft/min 

if  bit  1*1 


1  “  Limit  to  2000  ft/min 
if  bit  1  »  1 


TABLE  8-18 


ATCRBS  RESOLUTION  DATA* 


FIELD 

BITS 

INTERPRETATION 

ATCRBS  ID 

13 

ATCRBS  ID 

ATCRBS  ID  Availability 

1 

Set  ■  1  when  ATCRBS  ID  is 
available. 

Set  *  0  otherwise 

Resolution  Advisory 

10 

(See  Figure  8-17) 

VSL  Value 

2 

(See  Figure  8-17) 

First  Time  Transmitted 

1 

First  time  (1)  or  not  (0). 

Set  »  l  if  new  resolution 
advisory  (STFLG  set). 

Set  »  1  if  update  and  new 
resolution  advisory  .NE.  last 
successfully  delivered 
resolution  advisory 

Track  t 

3 

0  through  7 

Track  #  Unknown 

1 

Set  *  1  when  no  track  #  exists 
in  the  conflict  table  indicating 
that  multi-site  coordination 
has  not  occurred  over  ground 
lines. 

Set  ■  0  otherwise 

Handoff 

1 

Set  *  handoff  bit  in  ATSID 
indicating  that  aircraft 
has  left  ATARS  coverage  rone 

Spares 

16 

(Set  -  0) 

TOTAL 

48 

*  Requires  calculation  of  ATCRBS  Track  Block  Data 


TABLE  8-19 


SOURCE  OF  ATCRBS  RESOLUTION  DATA 

FIELD  SOURCE 

ATCRBS  ID  State  Vector  (CODE1) 

ATCRBS  ID  Availability  State  Vector 

Resolution  Advisory  Conflict  Table  and  Table  8-17 

VSL  Value  Conflict  Table  and  Table  8-17 

First  Time  Transmitted  Data  Link  Message  Pre-processing 

Task 

Track  #  and  Track  #  Compute  Criticality  Routine 

Unknown 

Handoff  Bit  Pair  Record  (ATSID) 


TABLE  8-20 


FIELD 


Range  to  ATCRBS 
Threat  (R) 


Range  Rate  to  ATCRBS 
Threat  (RD) 

Bearing  to  ATCRBS 
Threat  (THETA) 


Bearing  Rate  to  ATCRBS 
Threat  (THDOT) 

Altitude  of  ATCRBS 
Threat  (RZ) 

Altitude  Rate  of  ATCRBS 
Threat  (ZD) 

Spare 


TOTAL 


ATCRBS  TRACK  BLOCK  DATA 


BITS  INTERPRETATION 


8  Positive  binary  LSB  “  0.125  nmi. 

Largest  is  31.875  nmi  also  used  for 
greater  range 

7  Two's  complement  LSB  s  20  kts. 
Largest  value  is  +_  1260  kts 

8  Positive  binary  LSB  ■  1.40625°.  Use 
"bearing"  intermediate  calculation 
from  position  data 

7  Two's  complement  LSB  *  0.5  deg/sec. 

Largest  value  is  +_  31.5  deg/sec 

10  Positive  binary  LSB  »  100  ft. 

Largest  value  is  102,300  ft 

7  Two '8  complement  LSB  ■  2  ft /sec. 

Largest  value  i s  _♦  126  ft /sec 

1  Set  to  zero 


48 
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TABLE  8-21 


SOURCE  OP  ATCRBS  TRACK  BLOCK  DATA 


FIELD 

Range  to  ATCRBS 
Threat  (R) 

Range  Rate  to  ATCRBS 
Threat  (RD) 

Bearing  to  ATCRBS 
Threat  (THETA) 

Bearing  Rate  to  ATCRBS 
Threat  (THDOT) 

Altitude  of  ATCRBS 
Threat  (RZ) 

Altitude  Rate  of  ATCRBS 
Threat  (ZD) 


SOURCE 

Table  8-22,  Equation  I 
Table  8-22,  Equation  II 
Table  8-3,  BEARING 
Table  8-22,  Equation  III 
State  Vector 
Table  8-22,  Equation  IV 
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TABLE  8-22 

ATCRBS  TRACK  BLOCK  DATA  FIELDS 


I  Range  to  ATCRBS 

Threat  (R) 

VRZ  -  ZD2  -  ZD1 


XI  Range  Rate  to 

ATCRBS  Threat  (RD) 


SQRT  (RANGE2  +  RZ2) 


(DOT  +  RZ  *  VRZ)/R 


III  Bearing  Rate  to 

ATCRBS  Threat  (THDOT) 


See  Table  8-23 


Altitude  Bate  of  -  ^  *  1  “”/M  **' 

ATCRBS  Threat  (ZD) 
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TABLE  8-23 


COMPUTATION  OF  BEARING  RATE  TO  ATCRBS  THREAT 


Bearing  Rate  of  Threat  ■ 

(Velocity  of  threat  *  SIN  (Bearing  of  own  to  threat) 

♦  Velocity  of  own  *  SIN  (Bearing  of  threat) ) /range  to  threat 
-  own  turn  rate 


BEARING  RATE  1  -  (SQRT(XD22  +  YD22)  *  SIN  (BEARING  2) 

+  SQRT(XD12  +  YD12)  *  SIN  (BEARING  1))/SQRT( RANGE2) 
-  TURNRT  1 


BEARING  1  =  ARC  COS  ( A/ SQRT( RANGE2  *  (XDl2  +  YD12)  corrected  for 

proper  quadrant 

A  -  (X2  -  XI)  *  XDl  +  (Y2  -  Yl)  *  YD1 

BEARING  1  -  Bearing  of  AC2  seen  from  AC1 
BEARING  2  *  Bearing  of  AC1  seen  from  AC2 
BEARING  RATE  1  *  Bearing  rate  of  AC2  seen  from  AC1 
TURNRT  1  »  Turn  rate  of  AC1 


Note:  Formula  for  bearing  is  in  Table  8-3 
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OBJECT  AIRCRAFT 
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FIGURE  8-6 

SUBJECT  AIRCRAFT'S  PWILST  SEARCHED  FOR  ENTRY  “A” 
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3.  Encounter  type  "TN"  (threat  and  no  resolution)  means 
that  a  "TR"  encounter  type  would  normally  exist,  but  since 
the  site  does  not  have  priority,  the  Resolution  Segment  of 
the  normal  threat/resolution  pair  is  suppressed. 

4.  Encounter  type  "T"  (threat)  means  that  the  appropriate 
conditions  exist  for  generation  of  a  Threat  Segment. 

5.  Encounter  type  "P"  (proximity)  means  that  a  Proximity 
Segment  is  to  be  generated. 

6.  Encounter  type  "None"  means  that  the  site  is  not 
responsible  for  resolution  services  and  all  segments 
supporting  the  advisories  are  suppressed. 

Figure  8-7  provides  an  example  of  the  types  of  messages  generated 
for  various  primary /priority  states.  As  can  be  seen  from  this 
figure,  when  an  ATARS  site  constructs  messages  for  an  aircraft 
in  the  seam,  the  other  ATARS  site  which  shares  that  seam  will 
also  construct  messages  for  that  aircraft.  The  types  of  messages 
that  are  generated  depend  on  the  site  priority  in  relation  to 
the  subject  aircraft  and  the  status  of  the  DABS  sensor.  When 
the  site  has  priority,  resolution  advisories  are  generated.  When 
the  DABS  sensor  is  primary,  proximity  and  threat  advisories  are 
generated. 

The  tests  in  combinations  shown  below  determine  the  message 
types  that  will  be  uplinked  when  resolution  advisories,  threat 
advisories,  and  proximity  advisories  would  normally  all  exist. 

1.  All  advisory  types  are  uplinked  if 

a.  ATSID  *  local  ID  (site  has  priority)  and 

b.  the  sensor  is  primary. 

2.  Proximity  and  threat  advisories  on ly  are  uplinked  if 

a.  ATSID  is  not  equal  to  local  ID  (site  has  low 
priority)  and 

b.  the  sensor  is  primary. 

3.  No  advisories  are  uplinked  (site  is  not  responsible)  if 

a.  ATSID  is  not  equal  to  local  ID  (site  has  low 
priority)  and 

b.  the  sensor  is  not  primary. 

4.  Resolution  advisories  only  are  uplinked  if 
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SITE  1 

1 

SEAM 

SITE  2 

Site  1  is  primary  for  B,  C  and 

Site  2  is  primary  for  A  and  has 

has  priority  for  B,  C  pair 

priority  for  A,  B  pair 

Site  1  sends  resolution 
advisories  to  B  due  to  C 

Site  1  sends  resolution 
advisories  to  C  due  to  B 


Site  2  sends  resolution 
advisories  to  B  due  to  A 

Site  2  sends  resolution 
advisories  to  A  due  to  B 


Site  1  also  sends  threats 
and  proximities  to  C  due  to 
B,  to  B  due  to  C,  and  B 
due  to  A 


Site  2  also  sends  threats  and 
proximities  to  A  due  to  B,  but 
does  not  send  proximities  and 
threats  to  B  due  to  A 


FIGURE  8-7 

EXAMPLE  SHOWING  SITE  RESPONSIBILITY 
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a.  ATSID  =  local  ID  and 

b.  the  sensor  is  not  primary. 


8.3.2  PWILST  Initialization,  Update,  Deletion 

Entries  in  the  PWILST  from  the  previous  radar  cycle  are  sorted 
by  encounter  type.  When  new  data  for  an  encounter  pair  is 
processed,  all  entries  must  be  searched  for  a  match  because  new 
encounter  types  may  not  be  related  to  the  last  encounter  type  in 
a  predictable  way. 

To  process  new  data,  the  PWILST  is  searched  and  entries  are  added 
if  new,  or  updated  if  the  entry  already  exists.  For  new  entries, 
the  header  is  initialized  by  setting  the  Start  Flag  (STF1XJ), 
setting  the  New  Entry  Flag  (NEWFLG),  setting  the  Encounter  Type 
(TYPE),  and  resetting  the  End  Flag  (ENDFLG).  The  PWI  Number 
(PWINO)  field  is  not  updated  at  this  time.  For  updated  entries, 
STFLG  is  reset  for  successfully  delivered  start  encounter 
messages,  the  new  TYPE  is  set,  and  the  ENDFLG  is  reset.  After 
the  header  fields  are  entered,  all  data  required  for  the  message 
segments  is  calculated.  The  initialization/  update  cycle  is 
completed  in  the  Data  Link  Message  Construction  Task  by  assigning 
PWINO  and  setting  ENDFLG  as  each  message  is  constructed. 

PWILST  entries  may  be  deleted  when  site  priority  changes  or  DABS 
sensor  status  changes.  When  this  occurs,  the  segment  is  deleted 
and  former  messages  time  out  in  the  aircraft.  The  deletion  cycle 
is  completed  in  the  Data  Link  Message  Construction  Task  by  dele¬ 
ting  Resolution  Segments  when  the  aircraft  has  flown  outside 
ATARS  coverage  (allowing  messages  to  time  out),  by  sending  end 
resolution  messages  when  the  Resolution  Segment  is  not  updated, 
and  by  either  deleting  Threat  and  Proximity  Segments  (when  their 
numbers  are  needed  for  new  entries)  or  sending  end  encounter 
messages  when  Threat  Segments  or  Proximity  Segments  are  not 
updated. 

Further  details  of  the  Data  Link  Message  Pre-processing  Task 
are  shown  in  the  detailed  flow  charts  presented  in  Figures  8-8 
through  8-12.  Further  details  of  the  Data  Link  Message  Construc¬ 
tion  Task  are  discussed  in  Section  14. 
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MASTER  RESOLUTION  TASK 


The  Master  Resolution  Task  utilizes  the  outputs  of  the  ATARS 
Detect  Task  to  manage  encounters  and  determine  resolution 
advisories.  Its  functions  are: 

1.  Create  a  pair  record  and  create  or  update  conflict  table 
entries  on  the  first  scan  that  resolution  advisories  are 
requested  for  a  pair  of  aircraft. 

2.  Cause  resolution  advisories  to  be  issued  when  two 
requests  for  resolution  advisories  on  any  three  consecutive 
scans  have  been  generated  by  the  detection  logic  or  issue 
resolution  advisories  immediately  when  required  by  the 
MTTFLG  flag  setting. 

3.  Select  the  appropriate  positive  or  negative  resolution 
advisories  for  the  pair  using  the  Resolution  Evaluation 
Routine  (RER)  or  the  Multi-aircraft  Resolution  Routine. 
Positive  resolution  advisories  are  continued  for  a  least 
TSCMD  seconds  even  if  the  pair  drops  out  of  resolution 
advisory  status. 

4.  Monitor  the  change  in  the  resolution  dimension  predicted 
miss  distance  and  transition  resolution  advisories  between 
positive  and  negative  as  required. 

5.  Monitor  the  response  of  aircraft  to  ATARS  positive 
resolution  advisories  and,  if  necessary,  issue  additional 
resolution  advisories  in  the  event  of  apparent  non-response 
as  evidenced  by  a  diminishing  miss  distance  in  the 
resolution  dimension. 

Figure  9-1  is  the  description  of  the  Master  Resolution  Task. 

This  task  builds  a  multi-aircraft  data  structure  called  a 
conflict  table  along  with  pair  records  and  an  intermediate 
maneuver  table  for  each  conflict  pair.  The  conflict  table  is 
used  to  manage  multiple  encounters  in  which  the  aircraft  may  be 
involved. 

This  section  will  discuss  the  overall  strategy  of  the  task,  the 
basic  two-aircraft  resolution  case,  the  special  logic  which  is 
used  when  a  multi-aircraft  conflict  occurs,  and  the  handling  of 
non-responding  aircraft.  Because  the  logic  interacts  extensively 
with  the  conflict  table,  pair  records  and  intermediate  maneuver 
tables,  it  will  be  necessary  to  discuss  these  data  structures  in 
detail  first. 
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Conflict  Table,  Pair  Record  and  Intermediate  Maneuver 
Table  Data  Structures 


There  are  two  types  of  data  required  for  management  of  ATARS 
resolution: 

1.  inherently  pairwise  information,  such  as  time  at  which 

resolution  advisories  were  initiated  or  projected  miss 

distance  on  previous  scan,  and 

2.  multi-aircraft  information  concerning  the  entire 

cluster  of  conflicting  aircraft. 

Each  aircraft  involved  in  a  conflict  has  a  pointer,  CTPTR,  in 
its  system  state  vector  pointing  to  the  head  of  a  conflict  table. 
A  conflict  table  consists  of  one  line,  or  conflict  table  entry, 
for  each  aircraft  in  that  conflict.  The  conflict  table  entries 
are  linked  together  to  permit  easy  insertion  or  deletion  of  air¬ 
craft  (although  the  table  could  be  conceptually  regarded  as  a 
simple  array  of  conflict  table  entries).  The  Conflict  Table 
Head  (Table  9-1)  consists  of  the  count  of  the  number  of  aircraft 
in  the  cluster,  pointers  to  the  table  head  of  the  next  and  pre¬ 
vious  conflict  tables  in  the  linked  list  of  conflict  tables,  a 
flag  that  indicates  whether  any  aircraft  in  this  conflict  table 
is  in  an  ATARS  seam,  a  pointer  to  the  list  of  the  pair  records, 
and  a  pointer  to  the  first  of  the  conflict  table  entries.  The 
fields  in  each  Conflict  Table  Entry  (Table  9-2)  are  used  to 
record  information  about  the  aircraft  in  relation  to  the  conflict 
cluster,  and  to  record  the  effective  resolution  advisories  (VMAN 
and  HMAN)  for  each  aircraft. 

The  Intermediate  Maneuver  Table  Entry  (Table  9-3)  contains  the 
resolution  advisory  from  a  pair  record,  a  pointer  to  that  pair 
record,  and  a  pointer  to  the  next  intermediate  maneuver  table 
entry  for  the  same  aircraft  in  the  same  resolution  dimension. 

The  effective  resolution  advisory  in  each  dimension  in  the 
conflict  table  points  to  the  intermediate  maneuver  table  by  way 
of  ACIDH  or  ACIDV.  All  horizontal  or  all  vertical  resolution 
advisories  for  an  aircraft  are  linked  together  in  the  inter¬ 
mediate  maneuver  table.  However,  the  horizontal  resolution 
advisories  are  not  linked  to  the  vertical  resolution  advisories. 
The  use  of  the  intermediate  maneuver  table  simplifies  identifying 
all  the  pair  records  and  resolution  advisories  from  those  pair 
records  in  either  the  horizontal  or  vertical  dimension.  Also, 
the  effective  resolution  advisory  for  the  conflict  table  entry 
may  easily  be  determined  by  looking  at  the  intermediate  maneuver 
table  since  only  the  resolution  advisories  for  one  aircraft  in 
one  dimension  are  linked  together  and  pointed  to  by  ACIDH  or 
ACIDV. 
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TABLE  9-1 


FIELD 

NAC 

NEXTCT 

PREVCT 

SEAM 

PLIST 

FCTE 


LOGICAL  CONFLICT  TABLE  HEAD 


CONTENT 


Number  of  aircraft  currently  in  this  conflict  table. 

Pointer  to  the  next  conflict  table  in  the  linked  list  of 
conflict  tables. 

Pointer  to  the  previous  conflict  table  in  the  linked  list 
of  conflict  tables. 

A  flag  that  marks  this  as  a  seam  conflict  table. 

Pointer  to  first  pair  record  for  aircraft  in  this 
conflict  table. 

Pointer  to  first  conflict  table  entry  in  this  conflict 
table. 
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FIELD 

ACID 

HMAN 

ACIDH 

MULTH 

VMAN 

ACIDV 

MULTV 

NCON 

REMFLG 

NXTCTE 


TABLE  9-2 

LOGICAL  CONFLICT  TABLE  ENTRY 


CONTENT 


This  field  is  the  identity  of  the  aircraft  in  conflict, 
i.e.,  a  pointer  to  the  state  vector  of  the  aircraft. 

Effective  horizontal  resolution  advisory  being  sent  to 
the  aircraft. 

Pointer  to  an  entry  in  the  aircraft  intermediate  maneuver 
table  that  contains  a  pointer  to  the  pair  record  causing 
the  resolution  advisory  and  the  resolution  advisory  from 
the  pair  record. 

Count  of  the  number  of  pair  records  causing  a  horizontal 
resolution  advisory  to  this  aircraft. 

Effective  vertical  resolution  advisory  being  sent  to  the 
aircraft. 

Pointer  to  an  entry  in  the  aircraft  intermediate  maneuver 
table  that  contains  a  pointer  to  the  pair  record  causing 
the  resolution  advisory  and  the  resolution  advisory  from 
the  pair  record. 

Count  of  the  number  of  pair  records  causing  a  vertical 
resolution  advisory  to  this  aircraft. 

Number  of  conflict  pairs  in  which  this  aircraft  is 
involved.  Used  to  determine  when  the  conflict  table 
entry  may  be  deleted. 

Flag  that  indicates  that  this  aircraft  is  outside  the 
ATARS  mask  of  the  local  site. 

Pointer  to  next  conflict  table  entry  in  this  conflict 
table. 
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TABLE  9-3 


FIELD 
PRPTR 

RESADV  - 

NXTIM  - 


INTERMEDIATE  MANEUVER  TABLE  ENTRY 


CONTENT 


Pointer  to  the  pair  record  that  is  causing  this 
resolution  advisory. 

The  resolution  advisory  from  the  pair  record.  This  will 
be  a  horizontal  resolution  advisory  if  ACIDH  points  to 
this  entry  or  a  vertical  resolution  advisory  if  ACIDV 
points  to  this  entry. 

Pointer  to  the  next  entry  in  the  IM  table  that  is  also 
causing  a  resolution  advisory  to  the  same  aircraft  in  the 
same  dimension.  All  horizontal  resolution  advisories  are 
linked  together  and  all  vertical  resolution  advisories  are 
linked  together.  However  horizontal  resolution  advisories 
are  not  linked  to  vertical  resolution  advisories.  Null  if 
no  other  conflict  pairs  are  causing  a  resolution  advisory 
in  the  same  dimension. 
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For  every  aircraft  pair  declared  in  conflict,  a  pair  record 
is  created  and  linked  into  the  list  of  pair  records  for  this 
conflict  table.  The  Pair  Record  (Table  9-4)  contains  statistics 
on  the  particular  encounter  underway,  the  selected  resolution 
advisories  for  the  pair,  pointers  to  the  conflict  table  entries 
of  the  aircraft  involved,  the  identification  of  the  ATARS  func¬ 
tion  controlling  the  resolution  of  that  pairwise  conflict  or  an 
indication  of  BCAS  control. 

The  interplay  of  the  conflict  table,  intermediate  maneuver  table 
and  pair  records  (as  discussed  in  the  following  sections) 
permits: 


1.  The  selection  of  resolution  advisories  based  on  the 
status  of  the  entire  conflict  cluster  under  the  multi¬ 
aircraft  rules. 

2.  Management  of  possible  modifications  of  resolution 
advisories  due  to  negative-positive  and  positive-negative 
transitions,  or  non-responding  logic.  The  basic  data 
structures  used  by  the  algorithms  and  entries  for  a  sample 
three-aircraft  conflict  are  shown  in  Figure  9-2. 

9.2  Overview 


Figure  9-1  is  the  descriptive  flow  chart  of  the  Master  Resolution 
Task.  The  basic  strategy  of  the  task  is  to  select  resolution 
advisories  for  each  conflict  pair  based  on  the  status  of  all 
aircraft  in  a  conflict  cluster  (as  given  in  the  conflict  table). 
These  advisories  are  recorded  in  the  pair  record  and  are  moved 
into  the  intermediate  maneuver  table  before  the  effective  resolu¬ 
tion  advisory  is  placed  in  each  aircraft's  conflict  table  entry. 
Resolution  advisories  may  also  transition  from  negative  to 
positive  or  positive  to  negative  and  may  be  adjusted  by  the 
non-re sponding  logic. 

The  resolution  advisories  in  the  pair  record  may  be  thought  of 
as  representing  the  desired  resolution  advisories  for  this  pair. 
The  desired  resolution  advisories  are  moved  into  the  intermediate 
maneuver  table  and  the  highest  priority  resolution  advisory 
becomes  the  effective  resolution  advisory  in  the  conflict  table 
entry.  As  pairs  go  in  and  out  of  conflict,  various  pairs  in  a 
multi-aircraft  situation  will  have  their  resolution  advisories 
moved  into  the  table.  The  conflict  table  entry  indicates  if  more 
than  one  conflict  pair  is  contributing  to  a  resolution  advisory. 

The  detailed  logic  is  described  in  Figures  9-3  and  9-4  and 
discussion  of  logic  details  is  given  in  Section  9.7. 


TABLE  9-4 


LOGICAL  CONFLICT  PAIR  RECORD 


FIELD  CONTENT 

PAC1  -  Identity  of  one  aircraft  of  the  pair.  For  programming 

purposes  this  is  a  pointer  to  the  conflict  table  entry  for 
the  aircraft. 

PAC2  -  Identity  of  second  aircraft  of  the  pair.  For  programing 
purposes  this  is  a  pointer  to  the  conflict  table  entry  for 
the  aircraft. 

PMD  -  The  square  of  the  projected  horizontal  miss  distance  for 
the  pair  as  recorded  on  each  cycle. 

PVMD  -  The  projected  vertical  miss  distance  for  the  pair  as 
recorded  on  each  cycle. 

TSTART  -  The  time  at  which  the  present  resolution  advisories  in  the 
pair  record  were  selected.  The  precision  of  this  field  is 
sufficient  to  determine  the  sequence  of  selecting  resolu¬ 
tion  advisories  given  to  an  aircraft  for  more  than  one 
conflict  pair  in  the  same  ATARS  sector. 

POSCMD  -  A  control  variable  for  managing  the  2-out-of-3  conflict 

detection  logic  before  giving  resolution  advisories  and  for 
identifying  the  advisories  as  to  positive,  negative  or 
doubles. 

PHMAN1,  -  The  selected  horizontal,  vertical  resolution  advisories 

PHMAN2,  for  the  aircraft  in  the  pair.  Both  dimensions  will  not 

PVMAN1,  necessarily  be  used  simultaneously. 

PVMAN2 

TVSL1,  -  The  time  that  Vertical  Speed  Limit  (VSL)  advisories  were 

TVSL2  selected  for  each  aircraft. 

PIFR  -  Flag  to  indicate  any  controlled  aircraft  in  this  pair  is  to 
receive  an  ATARS  resolution  advisory. 

SEND1,  -  Flag  indicating  that  the  resolution  advisory  in  the  pair 

SEND2  record  entry  should  be  uplinked  for  this  aircraft.  SEND  is 

set  by  master  resolution  when  a  resolution  advisory  is 

computed  for  the  aircraft. 
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TABLE  9-4 


FIELD 
ATS  ID 

SECTID 

TRKID1 , 
TRKID2 

BIC1, 

BIC2 

PWISF 

INTR1 

INDX1 

CMDFL1 

INTR2 

INDX2 


LOGICAL  CONFLICT  PAIR  RECORD 
(Continued) 


CONTENT 


Identification  of  the  ATARS  processor  which  is  controlling 
the  resolution  of  this  pairwise  conflict.  One  bit  of  the 
ATSID  indicates  the  hand-off  status  of  ATARS  control. 

The  ATARS  sector  in  which  this  conflict  pair  was  detected. 

The  track  number  sent  to  aircraft  one  (two)  due  to  the 
proximity  advisory  caused  by  aircraft  two  (one). 

Counter  that  indicates  BCAS  control  of  this  aircraft  when 
its  value  is  greater  than  zero.  ATARS  is  in  control  of  the 
pair  when  the  value  of  both  variables  is  zero. 

Flag  to  indicate  that  coarse  screen  and  detection 
processing  has  already  been  done  for  this  pair  this  scan. 

Pointer  to  the  head  of  the  list  of  potential  domino 
conflict  aircraft  for  aircraft  PAC1. 

Value  indicates  which  pointer  in  the  Potential  Domino 
Conflict  List  Entry  to  use  when  searching  for  potential 
domino  conflict  aircraft  for  aircraft  PAC1 .  Value  is  one 
or  two. 

Each  bit  of  this  field  represents  a  resolution  advisory. 

If  the  bit  is  set,  then  the  respective  resolution  advisory 
was  accounted  for  when  determining  the  search  limits  used 
by  the  Domino  Coarse  Screen  Routine  in  the  selection  of  the 
present  list  of  potential  domino  conflict  aircraft. 

Pointer  to  the  head  of  the  list  of  potential  domino 
conflict  aircraft  for  aircraft  PAC2. 

Value  indicates  which  pointer  in  the  Potential  Domino 
Conflict  List  Entry  to  use  when  searching  for  potential 
domino  conflict  aircraft  for  aircraft  PAC2 .  Value  is  one 
or  two. 


TABLE  9-4 


FIELD 

CMDFL2 


NXTPR 


LOGICAL  CONFLICT  PAIR  RECORD 
(Concluded) 


CONTENT 

Each  bic  of  this  variable  represents  a  resolution 
advisory.  If  the  bit  is  set,  then  the  respective 
resolution  advisory  was  accounted  for  when  determining  the 
search  limits  used  by  the  Domino  Coarse  Screen  Routine  in 
the  selection  of  the  present  list  of  potential  domino 
conflict  aircraft. 

Pointer  to  next  pair  record  of  this  conflict  table. 
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AIRCRAFT  STATE 
VECTORS 


CTPTR  CT1 

CTE  CTE1 

(A/C  I) 


CTPTR 

CTE 

(A/C  2) 


CT1 

CTE2 


CTPTR 

CTE 

(A/C  3) 


CT1 

CTE3 


INTERMEDIATE 


MANEUVER 

TABLE 


PRPTR 

RESADV 

NXTIM 

PR1 

L 

NULL 

PR1 

R 

NULL 

PR2 

C 

NULL 

PR2 

D 

NULL 

CONFLICT 
TABLE  HEAD 


PAIR  RECORDS 


PAC1 

CTE1 

CTE2 

PAC2 

CTE3 

CTE3 

PMD 

MD2 

MD2 

PVMD 

ALT 

ALT 

TSTART 

TEN 

TEN 

POSCMD 

1  i 

l 

PHMAN1 

L 

PHMAN2 

R 

PVMAN1 

C 

PVMAN2 

D 

TVSL1 

TVSL2 

PIFR 

0 

0 

SEND1 

1 

1 

SEND2 

1 

1 

ATS  ID 

SECTID 

TRKID1 

TRKID2 

BIC1 

0 

0 

BIC2 

0 

0 

PWISF 

1 

1 

INTR1 

INDX2 

1 

1 

CMDFL1 

INTR2 

INDX2 

2 

2 

CMDFL2 

NXTPR 

PR2 

NULL 

NAC 

NEXTCT 

PREVCT 

SEAM 

PLIST 

FCTE 


NULL 


NULL 


PR1 


CTE1 


CONFLICT  TABLE  ENTRIES 
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L 

IM1 

1 

1 

0 

CTE2 
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C 

W&* 

1 

1 

0 

CTE3 
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R 

IM2 

1 

jtjpi 

IM4 

1 

2 

0 

NULL 

FIGURE  9-2 

DATA  STRUCTURES  USED  BY  MASTER  RESOLUTION 
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NUMBERS  IN  PARENTHESES  REFER 
TO  NOTES  IN  TABLE  9-7. 
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MASTER  RESOLUTION  TASK  (PAGE  1  OF  6) 
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9.3  Resolution  Initiation 


Because  ATARS  decisions  are  based  on  tracked  information  which 
is  subject  to  random  fluctuations  from  scan  to  scan,  it  is 
desirable  to  incorporate  logic  to  reduce  false  alarms  when 
dealing  with  resolution  advisories.  Incorporating  a  rule  which 
requires  the  conditions  for  issuing  resolution  advisories  to  be 
satisfied  on  two  consecutive  scans  normally  could  prevent 
unnecessary  resolution  advisories  because  of  errors  on  a  single 
scan.  But  this  rule  can  also  lead  to  late  alarms.  If  on  one 
scan  the  calculations  require  resolution  advisories,  but  on  the 
second  scan  they  do  not  (because  of  random  errors)  when  they 
should,  then  it  would  require  two  additional  scans  to  fully 
declare  the  conflict,  and  a  late  detection  would  occur.  To 
alleviate  this  problem,  a  rule  can  be  implemented  which  will 
issue  resolution  advisories  if  the  calculations  require  resolu¬ 
tion  advisories  on  any  two  of  three  consecutive  scans. 

The  exact  way  in  which  this  is  implemented  is  through  the  use  of 
a  state  transition  table  using  negative  values  for  states  of  the 
variable,  POSCMD.  When  a  request  for  resolution  advisories  is 
generated  for  a  given  pair,  a  pair  record  is  created  and  POSCMD 
is  set  to  -3.  POSCMD  is  then  updated  according  to  the  transition 
logic  in  Table  9-5.  POSCMD  is  updated  on  each  scan  that  master 
resolution  is  called,  until  POSCMD  reaches  a  value  of  +1.  If 
POSCMD  reaches  a  value  of  +1,  a  commitment  to  issue  resolution 
advisories  has  been  made.  The  MTTFLG  indicates  an  immediate 
need  for  resolution  advisories.  If  MTTFLG  is  set,  then 
resolution  advisories  are  calculated  immediately. 

The  Seam  Pair  Task  checks  the  CMDFLG  and  MTTFLG  settings.  When 
neither  is  set,  Conflict  Pair  Removal  Task  handles  the  updating 
of  POSCMD.  If  POSCMD  reaches  a  state  of  0  (zero),  the  pair  is 
declared  to  be  not  in  conflict  and  the  pair  record  is  deleted. 

The  conflict  table  entries  will  be  deleted  if  the  aircraft  are 
in  no  other  conflict. 

Resolution  advisories  are  monitored  to  determine  if  a  negative 
to  positive  or  positive  to  negative  transition  is  required.  If 
it  is,  the  new  resolution  advisories  are  reselected  and  entered 
in  the  pair  record.  When  a  negative  transitions  to  a  positive, 
the  TSTART  field  is  reset  to  force  the  positive  resolution 
advisory  to  continue  for  at  least  TSCMD  seconds.  If  positive 
resolution  advisories  have  been  issued  in  both  planes  in  the 
pair  record  for  the  given  pair  and  the  resolution  advisories  in 
one  plane  transition  to  negatives,  the  resolution  advisories  in 
the  other  plane  are  deleted. 


TABLE  9-5 


POSCMD  TRANSITION  TABLE 


NEW  VALUE  OP  POSCMD  BASED  ON 

PREVIOUS  POSCMD  VALUE  OF  FLAGS  FOR  CURRENT  SCAN 


MTTFLG 

Set 

Not  Set 

CMDFLG 

Set 

Not  Set 

-3 

+1 

-2 

N/A 

-2 

+  1 

+1 

-1 

-1 

+1 

+1 

0 
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9.4  Two  Aircraft  Resolution 


The  following  logic  is  used  to  resolve  all  conflict  pairs.  If  a 
conflict  is  part  of  a  multi-aircraft  situation,  there  may  be 
resolution  advisories  in  the  conflict  table  that  restrict  the 
choice  of  resolution  advisories  so  severely  that  the  special 
Multi-aircraft  Resolution  Routine  must  be  called.  However,  this 
is  not  always  true.  A  conflict  pair  may  be  part  of  a  larger 
multi-aircraft  conflict,  and  each  conflict  pair  may  still  be 
resolved  by  the  two-aircraft  resolution  logic. 

Note  in  the  flow  chart,  Figure  9-3,  that  the  resolution  advisory 
direction  for  horizontal  or  vertical  resolution  advisories  is  not 
recomputed  each  scan  except  in  an  explicit  resolution  advisory 
change  event  (Sections  9.6.2  and  9.6.3).  However,  selection  of 
resolution  advisories  is  tested  each  scan  to  determine  if  a 
positive-negative  or  negative-positive  transition  should  occur 
(Section  9.6.1). 

From  the  standpoint  of  the  algorithm  and  its  data  structures, 
the  two-aircraft  encounter  is  considered  as  simply  a  special 
case  of  an  arbitrary  N-aircraft  encounter:  i.e.,  the  same 
conflict  table  entries,  intermediate  maneuver  table  entries  and 
pair  records  are  constructed.  This  facilitates  programming  and 
provides  a  uniform  approach  which  permits  subsequent  aircraft  to 
be  easily  merged  into  the  two-aircraft  conflict  table. 

The  determination  of  resolution  advisories  for  the  unconstrained 
two-aircraft  case  is  accomplished  by  the  Resolution  Evalution 
Routine  (Section  10). 

9.5  Multi-aircraft  Resolution  Routine 


The  multi-aircraft  resolution  logic  uses  the  vertical  or 
horizontal  dimension  to  resolve  simultaneous  conflicts  between 
several  aircraft.  The  conflict  table  is  used  to  plan  the 
resolution  advisories  and  to  prevent  incompatible  resolution 
advisories  from  being  issued  to  an  aircraft. 

Conflicts  are  normally  resolved  according  to  the  standard  two- 
aircraft  rules  of  the  previous  section.  However,  in  the  case 
where  one  or  both  aircraft  in  a  pair  are  interacting  with  other 
aircraft,  the  conflict  table  must  be  examined  to  see  whether  the 
desired  horizontal  or  vertical  resolution  advisories  can  be  used. 
If  none  of  the  potential  resolution  advisories  can  be  used 
(Deliverable  and  Dimension  Available  Features  are  not  both 
favored  for  any  resolution  advisory),  then  the  Multi-aircraft 
Resolution  Routine  is  called. 
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As  a  rule,  if  RER  does  not  compute  advisories  because  both 
aircraft  are  already  receiving  advisories  or  the  only  available 
advisories  do  not  produce  at  least  a  minimum  acceptable  separa¬ 
tion,  then  multi-aircraft  resolution  logic  will  also  not  be  able 
to  compute  resolution  advisories.  However,  if  either  aircraft 
is  free  in  either  dimension,  then  multi-aircraft  resolution 
logic  may  be  able  to  compute  resolution  advisories  for  one  or 
both  aircraft  in  this  conflict  pair. 

The  Multi-aircraft  Resolution  Routine  first  determines  which 
resolution  advisories  are  available  for  each  of  the  maneuvered 
aircraft.  If  the  subject  aircraft  has  no  resolution  advisory  in 
its  conflict  table  entry  in  a  dimension  (VMAN  or  HMAN  is  null), 
but  is  causing  resolution  advisories  to  another  aircraft  because 
of  another  conflict  pair  (MULTV  or  MULTH  greater  than  zero), 
then  the  multi-aircraft  resolution  logic  must  determine  which 
resolution  advisories  are  compatible  with  the  previously  detected 
conflict.  This  is  done  by  computing  predicted  separation  values 
for  all  potential  resolution  advisories  for  the  subject  aircraft 
versus  the  resolution  advisory  already  given  to  the  previously 
maneuvered  aircraft.  If  the  predicted  separation  for  any  resolu¬ 
tion  advisory  satisfies  the  conditions  of  the  Deliverable  Feature 
(see  Table  10-8),  then  that  resolution  advisory  is  available. 

If  an  aircraft  has  a  resolution  advisory  in  its  conflict  table 
entry,  then  that  is  the  only  resolution  advisory  (or  its  nega¬ 
tive)  that  is  available  in  that  dimension  for  the  subject  air¬ 
craft.  This  determination  of  potential  resolution  advisories  is 
done  for  each  maneuvered  aircraft. 

If  an  aircraft  is  free  in  the  vertical  dimension,  then  both  a 
"climb"  and  "descend"  advisory  should  be  examined  for  accept¬ 
ability  with  the  previous  conflict.  We  would  normally  expect 
only  one  of  the  two  possible  vertical  advisories  to  be  compat¬ 
ible  with  the  resolution  of  a  conflict.  However,  if  both 
advisories  are  acceptable  then  both  advisories  should  become 
candidates  for  resolving  the  current  conflict,  regardless  of 
which  advisory  the  "eight  second  rule"  computed  for  this 
aircraft. 

After  determining  all  the  potential  resolution  advisories 
available  for  each  aircraft,  a  list  of  potential  resolution 
advisory  sets  is  created.  The  data  structure  of  the  resolution 
advisory  sets  is  that  shown  in  Table  10-2.  The  list  of  resolu¬ 
tion  advisory  sets  created  by  the  Multi-aircraft  Resolution 
Routine  will  be  a  subset  of  the  resolution  advisories  shown  in 
Table  10-1,  with  the  exception  of  a  possible  "climb'V'climb"  or 


"descend'V'descend"  combination.  The  resolution  advisory  sets 
created  are  those  obtained  by  forming  all  possible  combinations 
of  available  same  dimension  resolution  advisories  to  each  maneu¬ 
vered  aircraft  in  the  subject  pair.  Double  dimension  resolution 
advisories  are  obtained  by  forming  all  possible  combinations  of 
all  horizontal  resolution  advisory  sets  and  vertical  resolution 
advisory  sets.  Then  the  features  of  Table  9-6  are  evaluated  for 
each  resolution  advisory  set.  If  at  least  one  resolution 
advisory  set  has  the  Deliverable  Feature  set,  then  resolution 
advisories  can  be  given  to  this  pair  of  aircraft.  Otherwise, 
resolution  is  deferred  until  the  next  scan. 

Deferring  resolution  is  achieved  in  one  of  three  ways.  On 
initial  resolution  advisory  selection  for  a  pair,  no  resolution 
advisories  are  given  and  POSCMD  is  reset  to  -2.  On  deteriora¬ 
tion,  (IFRFLG  set),  the  PIFR  flag  is  not  set  in  the  pair  record 
and  no  resolution  advisory  is  given  to  the  controlled  aircraft. 

On  non-response,  do  nothing  (resolution  advisory  in  other  dimen¬ 
sion  can  not  be  added  at  this  time). 

If  an  aircraft  pair  having  resolution  deferred  is  from  the 
Normal  Resolution  List,  then  we  may  still  be  able  to  compute 
resolution  advisories  later  this  same  scan.  This  second  chance 
at  computing  resolution  advisories  is  obtained  by  placing  this 
conflict  pair  on  the  Delayed  Resolution  List  for  this  sector. 

The  pair  is  placed  on  the  Delayed  Resolution  List  and  the  LETID 
field  in  the  entry  is  set  to  reflect  this.  If  the  pair  for  which 
resolution  is  being  deferred  is  from  the  Delayed  Resolution  List, 
then  master  resolution  will  see  that  the  LETID  flag  indicates 
this  and  attempts  at  resolution  will  be  done  for  this  scan. 

If  a  pair  for  which  resolution  is  deferred  is  placed  on  the 
Delayed  Resolution  List,  then  some  of  the  same  values  will  be 
recomputed  on  the  second  pass  through  master  resolution  and  the 
Resolution  Evaluation  Routine  as  were  computed  on  the  first  pass. 
Any  values  that  would  not  change  between  the  first  pass  through 
master  resolution  and  the  second  pass  should  be  saved.  This 
would  include  some  of  the  values  in  the  Predicted  Separation 
(PSEP)  matrix. 

Multiple  encounters  are  handled  as  sequential  encounters  between 
pairs  even  if  they  are  detected  on  the  same  scan.  For  example, 
assume  three  aircraft  approaching  each  other  in  the  same  plane 
plus  one  aircraft  (A/C  #4)  crossing  below.  The  progression  of 
the  conflict  tables  and  pair  records  is  shown  in  Figure  9-5. 
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TABLE  9-6 


MULTI-AIRCRAFT  RESOLUTION  ADVISORY  EVALUATION  CRITERIA 


DELIVERABLE  -  If  this  is  the  first  scan  advisories  are  being  given, 
then  favor  this  advisory  if  the  predicted  separation  of  this  advisory 
is  greater  than  or  equal  to  the  predicted  separation  for  the  pair  if 
no  resolution  advisories  were  given. 

NEITHER  DOMINO  -  Favor  resolution  advisories  if  neither  aircraft  is 
predicted  to  be  in  another  conflict  because  of  these  resolution 
advisories. 

ONE  DOMINO  -  Favor  resolution  advisories  if  only  one  aircraft  is 
predicted  to  be  in  another  conflict  because  of  this  resolution 
advisory. 

PSEP  SEPl  -  Favor  resolution  advisories  where  predicted  3-D 
separation  is  greater  than  SEPl.  (Vertical  weighted). 

FAR  FROM  RADAR  -  Favor  single  vertical  resolution  advisory  if  either 
of  the  aircraft  is  further  than  RDISTR  from  the  radar  (i.e.,  SLREPS 
.GT.  RDISTR). 

NEGATIVE  SUFFICES  -  Favor  if  this  resolution  advisory  satisfies  the 
criteria  for  negative  resolution  advisories. 

NEGATIVE  DOES  NOT  REVERSE  MANEUVER  -  Favor  if  resolution  advisory  is 

negative,  the  pilot  is  maneuvering  and  the  negative  resolution 

advisory  will  not  force  him  to  stop  that  maneuver.  Turn  sensing  and 

vertical  rate  sensing  are  used  to  detect  a  maneuver. 

BIGGEST  PSEP  FOR  NEGATIVE  -  Favor  the  resolution  advisory  (or  resolu¬ 
tion  advisories)  giving  the  biggest  predicted  separation  which  has 
NEGATIVE  set. 

FAST  UNCMDED/SLOW  CMDED  -  Favor  double  resolution  advisories  for  a 
CMDED-UNCMDED  encounter  if  the  speed  ratio  of  the  UNCMDED  to  the 
CMDED  is  at  least  VRATIO,  the  UNCMDED  is  converging  with  a  vertical 
rate  in  excess  of  ZDTH,  and  the  track  crossing  angle  is  between  TXTHl 
and  TXTH2 . 

UNCMDED  WITH  LARGE  VERTICAL  RATE  -  Favor  horizontal  and  double 
resolution  advisories  if  the  UNCMDED  is  converging  in  altitude,  with 
a  vertical  rate  in  excess  of  ZDTH. 
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TABLE  9-6 


MULTI-AIRCRAFT  RESOLUTION  ADVISORY  EVALUATION  CRITERIA 

(Continued) 


NO  LEVEL  OFF  TIME  FOR  VERTICALS  -  Favor  horizontal  and  double 
resolution  advisories  if  the  aircraft  are  between  TV1  and  TV2  seconds 
from  vertical  crossing. 

DETERIORATION  -  Favor  double  resolution  advisories  if  the  pair  has 
satisfied  the  deterioration  logic  criteria  (PATH  *  1). 

AIRCRAFT  ON  FINAL  APPROACH  -  Favor  single  horizontal  advisories  for 
an  aircraft  in  the  final  approach  zone  (FAZ  set)  with  a  ground  speed 
of  less  than  VFAST . 

PATH  DEPENDENT  -  Favor  single  resolution  advisories  for  initial 
resolution  advisory  selection  and  transition  (PATH  *  0). 

PSEP  SEP2  -  Favor  resolution  advisories  where  predicted  3-D 
separation  is  greater  than  SEP2  (vertical  weighted). 

COMPATIBLE  WITH  TURN  -  Favor  resolution  advisory  where  horizontal 
part  of  resolution  advisory  is  not  the  opposite  of  a  turn  sensed  by 
the  tracker. 

BIG  VERTICAL  MISS  DISTANCE  -  Favor  vertical  and  double  resolution 
advisories  if  the  existing  vertical  miss  distance  is  at  least  ASEPV. 

BIG  HORIZONTAL  MISS  DISTANCE  -  Favor  horizontal  and  double  resolution 
advisories  if  the  square  of  the  projected  horizontal  miss  distance  is 
at  least  MDHSQ. 

SPEED  CHECK  -  Favor  vertical  and  double  resolution  advisories  if 
either  maneuvered  aircraft  has  a  speed  greater  than  VFAST.  Favor 
horizontal  and  double  resolution  advisories  if  all  maneuvered 
aircraft  (one  or  both  aircraft)  have  speeds  below  VSLOW. 

REINFORCES  PRIOR  RESOLUTION  ADVISORIES  -  Favor  resolution  advisory 
that  has  the  same  sense  as  the  resolution  advisory  given  on  the 
previous  scan.  A  double  resolution  advisory  given  after  a  single 
resolution  advisory  is  compatible  if  it  includes  that  single 
resolution  advisory  (see  Table  10-9). 


TABLE  9-6 


MULTI-AIRCRAFT  RESOLUTION  ADVISORY  EVALUATION  CRITERIA 

(Concluded) 


REINFORCES  TURN  -  Favor  resolution  advisory  when  horizontal  part  of 
the  resolution  advisory  reinforces  a  turn  sensed  by  the  tracker. 

BIGGEST  PSEP  -  For  all  resolution  advisories  (single  horizontal, 
single  vertical,  double)  favor  the  resolution  advisory  with  the 
largest  predicted  3-D  separation. 
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The  first  conflict  detected  is  between  A/C  #1  and  A/C  #2,  both 
at  the  same  altitude.  The  resolution  is  achieved  using  a 
horizontal  turn  given  to  A/C  #1  and  a  table  entry  is  made  as 
shown  in  the  figure.  (A/C  #1  is  uncontrolled,  while  A/C  #2,  #3, 
and  #4  are  controlled).  On  the  next  scan,  a  conflict  situation 
is  detected  between  A/C  #2  and  A/C  #3.  A/C  #3  is  directed  to 
climb  and  A/C  #2  is  directed  to  descend.  The  next  conflict 
occurs  between  A/C  #2  and  A/C  #4  which  is  at  a  lower  altitude. 

A  horizontal  maneuver  is  used  to  resolve  this  conflict.  The 
resolution  advisory  given  to  A/C  #2  because  of  A/C  #4  has  been 
checked  as  being  compatible  with  the  advisory  to  A/C  #1,  but  it 
is  not  placed  in  the  A/C  #2  -  A/C  #1  pair  record.  At  this  point, 
it  is  necessary  to  change  the  value  of  the  look-ahead  time  in 
the  detection  logic  if  provision  is  to  be  made  for  handling  an 
additional  conflict  with  the  above  aircraft.  , 

As  collision  situations  are  resolved  and  aircraft  pass  clear  of 
each  other,  the  aircraft  are  dropped  from  the  table  and  their 
pair  records  are  deleted. 


9.6  Resolution  Change  Logic 


9.6.1  Positive/Negative  Transition 


Resolution  advisories  are  monitored  to  determine  if  a  negative 
to  positive  transition  is  required  or  a  positive  to  negative 
transition  is  allowed.  If  it  is,  the  new  resolution  advisories 
are  reselected  and  entered  in  the  pair  record.  When  a  negative 
transitions  to  a  positive,  the  TSTART  field  is  reset  to  force 
the  positive  resolution  advisory  to  continue  for  at  least  TSCMD 
seconds.  If  positive  resolution  advisories  have  been  issued  in 
both  planes  in  the  pair  record  for  the  given  pair  and  the 
resolution  advisories  in  one  plane  transition  to  negatives,  the 
resolution  advisories  in  the  other  plane  are  deleted. 


9.6.2  Control led/Uncontrol led  hot 


When  a  controlled  aircraft  and  an  uncontrolled  aircraft  are 
paired  together  by  the  coarse  screen  logic,  normally  the 
uncontrolled  aircraft  is  maneuvered  without  maneuvering  the 
controlled  aircraft.  This  is  accomplished  by  using  larger  tau 
and  immediate  separation  thresholds  to  determine  the  need  for 
the  uncontrolled  aircraft's  advisory.  If  however,  on  a  later 
scan  we  determine  that  the  tau  and  separation  values  have  become 
small  enough  to  warrant  maneuvering  the  controlled  aircraft, 

RER  is  called  to  compute  advisories  for  both  aircraft. 
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If  RER  is  able  to  compute  advisories  for  both  aircraft,  then  the 
PIFR  flag  is  set  in  the  pair  record.  If  RER  is  not  able  to 
compute  an  advisory  for  the  controlled  aircraft,  PIFR  is  not 
set,  and  resolution  is  deferred.  Note  that  the  advisory  to  the 
uncontrolled  aircraft  should  not  be  deleted  from  the  pair  record. 
If  this  pair  was  from  the  Normal  Resolution  List,  then  set  the 
LETID  flag  appropriately  and  place  this  pair  on  the  Delayed 
Resolution  List.  This  will  give  RER  a  second  chance  on  this 
same  scan  to  try  to  compute  an  advisory  for  the  controlled 
aircraft. 

9.6.3  Non-responding  Logic 

Additional  logic  makes  a  provision  for  recomputing  and  changing 
positive  resolution  advisories  when  either  or  both  aircraft  have 
not  adequately  responded  to  the  resolution  advisories.  The 
horizontal  (vertical)  maneuver  is  recomputed  on  the  first  scan 
at  least  TRECOM  after  TSTART  at  which  the  square  of  the  projected 
horizontal  miss  distance,  MD2,  (vertical  miss  distance,  ALT)  is 
less  than  the  square  of  the  projected  horizontal  miss  distance 
(vertical  miss  distance)  on  the  previous  scan. 

Note  that  the  changed  and/or  additional  resolution  advisories 
continue  to  be  sent  to  the  non-responding  aircraft  since  it  may 
comply  at  a  later  time. 

9.7  Detailed  Logic  Notes 

The  master  resolution  algorithm  involves  the  manipulation  of 
dynamic  data  structures  and  has  several  sections.  A  detailed 
description  of  the  logic  and  data  structures  is  provided  below. 

Certain  of  the  flow  -  .iart  blocks  involve  terms  such  as  "set  VMAN 
to  the  highest  priority  advisory"  which  are  essential  to  the  be¬ 
havior  of  the  system.  However,  including  the  complete  logic  in 
the  flow  charts  would  obscure  the  basic  structure  of  the  logic. 
The  notes  in  this  section  are  intended  to  annotate  the  flow 
charts  and  not  discuss  the  rationale  or  behavior  of  the  algo¬ 
rithms.  Clearly,  the  algorithms  require  some  type  of  dynamic 
storage  allocation  facility.  This  could  be  done  even  in  a 
language  like  FORTRAN  by  defining  a  suitable  set  of  service 
routines. 

The  use  of  the  conflict  table,  intermediate  maneuver  table  and 
pair  record  data  structures  should  permit  implementation  of 
different  multi-aircraft  strategies  if  changes  are  indicated  by 
the  continuing  ATARS  test  and  analysis  efforts. 


Reference  should  be  made  to  the  following  additional  tables  and 
figures  while  reading  the  explanatory  notes  in  Table  9-7: 


Illustration 

Title 

Figure  9-1 
Figure  9-2 
Figure  9-3 

Description  of  Master  Resolution  Task 

Data  Structures  Used  by  Master  Resolution 
Master  Resolution  Task 

Table  9-1 

Table  9-2 

Table  9-3 

Table  9-4 

Table  9-5 

Table  9-8 

Logical  Conflict  Table  Head 

Logical  Conflict  Table  Entry 

Intermediate  Maneuver  Table  Entry 

Logical  Conflict  Pair  Record 

POSCMD  Transition  Table 

Effective  Resolution  Advisory  Determination 

The  text  of  the  table  is  keyed  to  referenced  sections  of  logic 
numbered  in  Figure  9-3.  Also  necessary  to  the  understanding  of 
the  determination  of  effective  resolution  advisories  is  Table 
9-8. 
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TABLE  9-7 


LOGIC  DETAILS  OF  MASTER  RESOLUTION  ALGORITHM 


Level  Logic  (Figure  9-3,  Page  1) 


The  master  resolution  algorithm  is  entered  after  the  detection 
logic  has  been  performed  for  a  candidate  aircraft  pair  generated 
in  the  coarse  screening  logic.  Only  those  aircraft  pairs  requiring 
resolution  advisories  are  processed  by  the  master  resolution  logic. 
The  top  level  actions  are  to  manipulate  the  data  structures  and 
decide  when  to  compute  or  recompute  resolution  advisories. 


Reference 


Description 


1  The  state  vector  of  each  aircraft  contains  the 

CTPTR  pointer  which  points  to  the  aircraft's 
conflict  table.  If  either  of  the  pointers  for  the 
pair  are  null  or  they  point  to  different  tables, 
then  no  pair  record  exists.  If  the  pointers  are 
identical,  then  we  search  along  the  linked  list 
headed  by  PLIST  until  we  find  a  pair  record  whose 
PAC1  and  PAC2  fields  point  to  the  conflict  table 
entries  of  this  pair  of  aircraft.  (Note  that  if 
the  number  of  aircraft  in  the  table,  NAC,  is  2  then 
the  pair  record  pointed  to  immediately  by  PLIST 
must  be  this  pair).  It  is  advisable  to  save  a 
pointer  to  the  found  pair  record  for  use  in  sub¬ 
sequent  processing  steps. 


If  no  pair  record  exists,  the  pair  record  must  be 
created  and  its  fields  initialized.  Depending  on 
the  conflict  tables  that  may  exist  due  to  other 
conflict  pairs,  the  following  actions  must  occur. 

a.  If  both  aircraft  are  not  in  a  conflict  table, 
one  is  created  and  the  new  pair  record  linked  onto 
its  pair  list. 

b.  If  one  aircraft  is  in  a  table  and  the  other  is 
not,  a  conflict  table  entry  for  the  new  aircraft  is 
created,  added  to  the  existing  table,  and  the  new 
pair  record  linked  onto  the  pair  list. 


TABLE  9-7 


LOGIC  DETAILS  OF  MASTER  RESOLUTION  ALGORITHM 
( Continued) 


c.  If  both  aircraft  in  the  pair  are  already  in  the 
same  conflict  table,  the  pair  record  is  linked  onto 
the  conflict  table's  pair  list. 

d.  If  each  aircraft  is  in  a  different  table,  the 
tables  and  pair  lists  are  merged  and  the  new  pair 
record  linked  onto  the  pair  list.  Note  that  one  of 
the  existing  table  heads  is  superfluous  and  is 
deleted. 


During  each  of  these  actions,  the  number  of 
aircraft,  field,  NAC,  in  the  resulting  table,  must 
be  appropriately  incremented.  The  NCON  field  in 
each  aircraft' s  conflict  table  entry  is  incremented 
to  reflect  the  presence  of  the  new  conflict  pair. 
The  CTPTR  fields  in  each  aircraft's  state  vector 
must  be  appropriately  adjusted. 

2.  Initial  Resolution  Advisory  Select  Logic  (Figure  9-3,  Page  2) 

The  initial  resolution  advisory  select  logic  selects  the 
resolution  advisories  for  the  pair  of  aircraft  and  enters  them 
into  the  pair  record.  This  page  of  logic  is  entered  when  a  pair 
record  exists,  the  CMDFLG  is  set,  and  no  resolution  advisories 
have  been  selected  in  the  pair  record. 


Re  ference 


3 


4 


Description 

RER  chooses  the  appropriate  resolution  advisories 
for  the  pair.  If  only  one  aircraft  is  to  be 
maneuvered,  no  resolution  advisory  will  be 
determined  for  the  unmaneuvered  aircraft  and  a  null 
entry  is  placed  in  the  pair  record  for  that 
aircraft.  The  domino  and  multi-aircraft  resolution 
logic  is  a  subset  of  the  RER.  RER  determines  when 
to  call  both  of  these  routines. 

If  resolution  advisories  could  not  be  computed  for 
the  pair  of  aircraft  due  to  other  conflict 
constraints,  then  resolution  is  deferred  until  the 
next  scan.  This  is  accomplished  at  initial 
resolution  advisory  selection  by  resetting  POSCMD 
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to  -2.  If  the  CMDFLG  is  set  again  on  either  of  the 
next  two  scans  for  this  pair,  then  master  resolution 
will  again  call  the  RER  to  compute  resolution 
advisories.  If  this  pair  was  from  the  Normal 
Resolution  List  then  attempt  resolution  again  this 
scan  by  placing  this  pair  on  the  Delayed  Resolution 
List. 

The  Path  variable  tells  the  RER  which  advisories  to 
favor;  single  dimension  or  double  dimension. 

PATH=0  means  to  favor  single  dimension  advisories 
and  PATH^l  means  to  favor  double  dimension 
advisories.  Single  dimension  advisories  are 
favored  on  initial  advisory  selection,  uncontrolled/ 
controlled  advisory  addition,  and  positive  to 
negative  and  negative  to  positive  advisory 
transition.  Double  dimension  advisories  are 
favored  when  the  situation  is  deteriorating  as 
evidenced  by  a  decreasing  miss  distance  in  the 
resolution  dimension. 

5  If  horizontal  resolution  advisories  were  computed, 

then  both  advisories  are  either  positive  or 
negative.  If  vertical  resolution  advisories  were 
computed,  both  advisories  are  positive  or  negative, 
unless  a  "descend"  resolution  advisory  was  computed 
for  an  aircraft  below  ATERN  altitude  AGL.  In  this 
case,  one  advisory  is  positive  and  one  negative. 

This  case  should  be  treated  as  positive  advisories. 

3.  Post  Resolution  Advisories  from  Pair  Record  to  Conflict  Table 
(Figure  9-3,  Page  3) 

In  general,  the  pair  record  contains  the  resolution  advisories  to 
resolve  a  particular  conflict  pair  selected  in  the  initial 
resolution  advisory  select  logic  or  modified  in  the  resolution 
advisory  change  logic.  Because  of  prior  conflicts,  the  effective 
resolution  advisories  in  the  conflict  table  entry  are  not  always 
identical  with  the  advisories  in  the  pair  record.  This  section  of 
logic  moves  resolution  advisories  from  the  pair  record  to  the 
conflict  table  through  the  use  of  the  interrsediate  maneuver  table. 
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This  staging  of  resolution  advisories  from  the  pair  record  to  the 
conflict  table  permits: 

a.  resolution  advisories  to  be  changed  or  added  due  to  events 
in  this  pair,  and 

b.  proper  changes  in  the  remaining  resolution  advisories  when 
pairs  go  in  or  out  of  conflict. 

Reference  Description 

6  If  the  resolution  advisory  in  the  pair  record  is 

null,  we  must  distinguish  between  no  resolution 
advisory  and  a  null  advisory.  A  null  advisory  may 
be  given  to  a  controlled  aircraft  while  the 
uncontrolled  aircraft  is  receiving  a  resolution 
advisory  in  this  dimension.  This  may  be  done  by 
using  different  codes  in  the  pair  record  for  no 
resolution  advisory  and  for  a  null  resolution 
advisory  (see  Table  10-3). 

The  intermediate  maneuver  table  contains  a 
resolution  advisory  in  one  dimension  and  a  pointer 
to  the  pair  record  causing  the  advisory. 

If  there  is  a  resolution  advisory  in  the  pair 
record  this  scan,  then  check  the  intermediate 
maneuver  table.  If  this  pair  record  is  already  in 
the  intermediate  maneuver  table  in  this  dimension, 
then  simply  update  the  advisory  to  the  advisory  in 
the  pair  record.  If  the  pair  record  is  not  already 
in  the  intermediate  maneuver  table  in  this 
dimension,  then  add  an  entry  for  this  pair  record, 
add  the  resolution  advisory  and  increment  MULTH 
(MULTV)  in  the  conflict  table  entry. 

If  no  resolution  advisory  appears  in  the  pair 
record  for  an  aircraft,  then  no  entry  needs  to  be 
made  in  the  intermediate  maneuver  table.  This  is 
not  true  when  a  controlled  aircraft  has  a  null 
resolution  advisory  in  a  dimension  but  the  uncon¬ 
trolled  aircraft  it  is  paired  with  does  have  a 
resolution  advisory  in  that  dimension.  F  .  that 
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dimension  only,  a  null  resolution  advisory  entry  is 
made  in  the  intermediate  maneuver  table  and 
factored  into  the  effective  resolution  advisory  in 
the  conflict  table  entry.  The  MULTH  or  MULTV 
counter  is  incremented  also. 

7  A  resolution  advisory  is  being  deleted  for  this 

aircraft  based  on  this  particular  pair  record. 
However,  this  aircraft  may  require  another  advisory 
based  on  another  pair.  Yet  the  other  pair  may  have 
been  processed  already  this  scan,  so  that  there 
would  be  a  one  scan  delay  in  setting  the  conflict 
table  entry  advisory  to  the  advisory  from  the 
second  pair.  Therefore,  advisories  caused  by  other 
pairs  are  checked  for  and  sent  to  the  conflict 
table  entries  at  this  point,  regardless  of  whether 
the  other  pair  has  already  been  processed  this  scan. 

8  The  highest  level  resolution  advisory  should  be 

placed  in  the  conflict  table  entry.  In  most  cases, 
only  one  pair  record  will  be  causing  an  advisory  to 
an  aircraft  in  a  dimension  (MULTH  or  MULTV  =1).  In 
this  case,  the  advisory  may  be  moved  directly  from 
the  intermediate  maneuver  table  to  the  conflict 
table  entry. 

If  more  than  one  pair  record  is  causing  an  advisory 
in  one  dimension,  the  highest  level  advisory  is 
moved  to  the  conflict  table  entry.  The  RER  should 
not  pick  conflicting  sense  advisories,  but  because 
of  seam  conflicts  and  BCAS  chosen  advisories, 
conflicting  sense  resolution  advisories  should  be 
accounted  for. 

In  the  horizontal  dimension,  there  are  only  two 
levels  of  advisories,  positive  and  negative.  In 
the  vertical  dimension  there  are  three  levels, 
positive,  negative  and  VSL.  Within  the  VSL  level, 
there  are  three  sublevels.  The  positive  advisories 
are  the  highest  level,  while  negative  advisories 
are  next  and  VSL' 8  the  lowest  level. 
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Table  9-8  indicates  the  decisions  to  be  made  in 
choosing  the  highest  level  advisory.  Even  though 
there  may  be  more  than  two  advisories,  the  decision 
may  be  made  between  two  advisories  at  a  time;  an 
advisory  in  the  intermediate  maneuver  table  and  the 
effective  advisory  already  in  the  conflict  table 
entry. 

Resolution  Advisory  Change  Logic  (Figure  9-3,  Pages  4,  5,  6) 

There  are  three  ways  in  which  resolution  advisories  can  be 
modified  once  they  are  selected  in  the  initial  resolution  advisory 
select  logic: 

a.  a  controlled  aircraft  requiring  a  resolution  advisory 
(Page  4), 

b.  a  positive  to  negative  or  negative  to  positive  resolution 
advisory  transition  (Page  5), 

c.  a  non-responding  aircraft  in  the  pair  (Page  6). 

The  non-responding  logic  monitors  the  conflict  and  adds  another 
resolution  advisory  if  one  aircraft  did  not  respond  as  indicated 
by  a  diminishing  horizontal  or  vertical  miss  distance. 

POSCMD  is  a  control  variable  used  to  implement  this  logic. 

Prior  to  the  commitment  to  issue  resolution  advisories,  POSCMD 
takes  a  series  of  negative  values.  These  are  explained  in  Section 
9.3.  The  non-negative  values  of  POSCMD  and  their  meanings  are 
listed  below. 

POSCMD  =  0  Negative  resolution  advisories  selected 

POSCMD  *  1  Positive  resolution  advisories  have  been  computed  and 

entered  in  the  pair  record.  An  additional  maneuver 
has  not  yet  been  generated. 

POSCMD  ■  2  A  horizontal  or  vertical  maneuver  has  been  recomputed, 
and  stored  in  the  pair  record  because  a  decrease  in 
projected  horizontal  or  vertical  miss  distance  has 
been  detected. 
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4.  Recomputation  of  Resolution  Advisories  when  Controlled/ 
Uncontrolled  Conflict  Cannot  be  Resolved  by  Maneuvering  Only 
the  Uncontrolled  (Figure  9-3,  Page  43 

9  It  is  now  necessary  to  give  a  resolution  advisory 

to  the  controlled  aircraft.  However,  it  is 
possible  that  since  the  scan  on  which  the 
uncontrolled  aircraft  received  its  resolution 
advisory,  the  controlled  aircraft  has  acquired 
constraints  on  it  due  to  other  conflicts.  If  a 
resolution  advisory  can  not  be  given  to  the 
controlled  aircraft  for  this  conflict  pair,  then 
resolution  must  be  deferred.  This  is  done  by 
keeping  the  advisory  to  the  uncontrolled  aircraft, 
but  not  setting  the  PIFR  flag  in  the  pair  record. 
Then,  if  the  IFRFLG  is  set  again  on  the  next  scan, 
again  attempt  to  compute  resolution  advisories  for 
the  controlled  aircraft.  Instead  of  just  deferring 
resolution  to  the  next  scan,  if  this  pair  was  from 
the  Normal  Resolution  List,  then  place  the  pair  on 
the  Delayed  Resolution  List  and  set  the  LETID  flag 
in  the  entry  appropriately. 

10  Comment  5  applies  here  also. 

5.  Resolution  Advisory  Transition  Logic  (Figure  9-3,  Page  5) 

11  If  POSCMD=0,  then  negative  resolution  advisories 
are  in  the  pair  record.  If  POSCMD  is  greater  than 
0,  then  positive  single  or  double  dimension 
advisories  are  in  the  pair  record.  Check  for 
transition  only  if  the  positive  advisories  have 
been  in  the  pair  record  at  least  TSCMD  seconds. 

12  If  resolution  advisories  appear  in  the  pair  record 
in  this  dimension,  check  their  sense  (positive  or 
negative)  against  the  sense  of  advisories  necessary 
as  indicated  by  the  projected  miss  distance.  While 
the  test  for  the  Negative  Suffices  Feature  in  RER 
involves  more  than  simply  a  miss  distance  check, 
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the  miss  distance  check  is  the  best  single 
indicator  of  the  need  for  positive  or  negative 
advisories. 

13  Comment  5  applies  here  also. 

14  Comment  5  explains  why  the  vertical  dimension  test 
is  an  "OR"  test  while  the  horizontal  dimension  test 
is  an  "AND"  test. 

6.  Non-responding  Logic  (Figure  9-3,  Page  6) 

15  Positive,  single  dimension  resolution  advisories 
must  have  been  given  for  at  least  TRECOM  seconds 
before  a  check  for  the  necessity  for  double  dimen¬ 
sion  advisories  is  made  .  If,  after  TRECOM  seconds 
of  positive  advisories,  the  projected  miss  distance 
in  the  resolution  dimension  diminishes  from  the 
previous  scan,  then  call  the  RER  to  compute  two 
dimensional  resolution  advisories.  If  double  advis¬ 
ories  can  not  be  computed,  defer  resolution  by 
leaving  POSCMD  set  to  1.  Attempts  will  be  made  to 
compute  double  dimension  advisories  on  any  subse¬ 
quent  scan  on  which  the  projected  miss  distance 
decreases  in  the  resolution  dimension  from  the 
previous  scan. 
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10.  RESOLUTION  EVALUATION  ROUTINE 


The  Resolution  Evaluation  Routine  (RER)  is  called  by  the  Master 
Resolution  Task  to  determine  maneuvers  for  a  pair  of  aircraft 
requiring  resolution  advisories.  RER  receives  as  input  the 
aircraft  state  vectors,  the  values  computed  in  the  Detect  Task, 
and  any  conflict  tables,  intermediate  maneuver  tables  and  pair 
records  that  exist.  The  module  generates  positive  or  negative 
horizontal  or  vertical  resolution  advisories  or  Vertical  Speed 
Limit  (VSL)  resolution  advisories  for  each  maneuvered  aircraft. 
The  description  of  the  Resolution  Evaluation  Routine  is  presented 
in  Figure  10-1. 

Resolution  advisories  are  generated  by  evaluating  all  resolution 
advisory  sets  and  picking  the  set  with  the  highest  total  value 
of  favored  features.  To  reduce  computation,  only  a  subset  of 
all  possible  resolution  advisory  sets  is  considered.  This  subset 
consists  of  the  25  resolution  advisories  shown  in  Table  10-1. 

The  associated  data  structure  is  Table  10-2.  Table  10-3  gives 
the  definition  of  the  codes  used  in  Table  10-1. 

Of  the  25  resolution  advisories,  nine  maneuver  both  aircraft, 
eight  maneuver  only  the  first  and  the  other  eight  maneuver  only 
the  second.  Whether  both  aircraft  are  to  be  maneuvered  is  a 
function  of  the  aircraft  configuration  (controlled/uncontrolled, 
equipped/unequipped),  the  flags  set  in  the  Detect  Task,  and  the 
zone  where  the  conflict  takes  place  (see  Tables  10-4  and  10-5). 
Aircraft  which  are  to  receive  a  resolution  advisory  are  maneu¬ 
vered  and  those  which  are  not  are  unmaneuvered.  After  the 
maneuvering  aircraft  are  determined,  the  25  resolution  advisories 
in  Table  10-1  are  reduced  to  eight  or  nine  applicable  resolution 
advisories. 

The  set  of  resolution  advisories  may  be  implemented  as  a  list  of 
data  structures  linked  together.  The  data  structure  for  a 
resolution  advisory  is  shown  in  Table  10-2.  Some  of  the  data 
fields  describe  intrinsic  properties  of  each  resolution  advisory 
and  are  hardwired,  while  others  depend  on  the  encounter  and  are 
computed  by  the  resolution  evaluation  logic.  Some  of  the  inform¬ 
ation  in  the  resolution  advisory  data  structure  is  redundant,  but 
is  included  to  simplify  the  evaluation  logic. 

When  both  aircraft  are  expected  to  respond  to  resolution  advi¬ 
sories,  there  is  only  one  sensible  vertical  resolution  advisory 
pair.  This  sensible  vertical  resolution  advisory  pair  can  be 
found  by  projecting  the  aircraft  ahead  eight  seconds  and  giving 
the  aircraft  on  top  a  "climb"  and  the  one  below  a  "descend." 

For  the  resolution  advisories  that  maneuver  both  aircraft  in  the 
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DESCRIPTION  OF  RESOLUTION  EVALUATION  ROUTINE 
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TABLE  10-1 


SET  OF  RESOLUTION  ADVISORIES  TO  BE  EVALUATED 


TL/- 

TR/- 

C/- 

0/- 

TL/-  C/- 
TR/-  C/- 
TL/-  D/- 
TR/-  □/- 
TL/TL 

TL/TL  VERT 
tl/tr 

TL/TP  VERT 

VERT 

TR/TL 

TR/TL  VERT 
TR/TR 

TR/TR  VERT 

-/TL 

-/TR 

-/C 

-/D 

-/TL  -/C 
-/TR  -/C 
-/TL  -/O 
-/TR  -/D 


*  Will  be  replaced  by  the  appropriate  vertical  resolution  advisories, 
picked  using  the  "eight  second  rule." 

A  CMDED  -  maneuvered  (commanded);  UNCMDED  -  unmaneuvered  (uncommanded) 

B  The  numerical  coding  scheme  for  the  resolution  advisories  is  given  in 
Table  10-3. 


C  1  -  True,  0  -  False 


TABLE  10-2 


FIELD 

HI 

VI 

H2 

V2 

SINGLE 

HORIZ 

VERT 

CMDED-CMDED 

CMDED-UNCMDED  - 

UNCMDED-CMDED  - 

NEGATIVE 

BELOWIOOO 

INDEX1 


RESOLUTION  ADVISORY  DATA  STRUCTURE 


DEFINITION 


Horizontal  component  of  resolution  advisory  to 
aircraft  1. 

Vertical  component  of  resolution  advisory  to 
aircraft  1. 

Horizontal  component  of  resolution  advisory  to 
aircraft  2. 

Vertical  component  of  resolution  advisory  to 
aircraft  2. 

Set  if  resolution  advisories  are  only  horizontal  or 
only  vertical. 

Set  if  there  is  a  horizontal  component  to  this 
resolution  advisory. 

Set  if  there  is  a  vertical  component  to  this 
resolution  advisory. 

Set  if  this  resolution  advisory  maneuvers  both 
aircraft . 

Set  if  this  resolution  advisory  maneuvers  only  the 
first  aircraft. 

Set  if  this  resolution  advisory  maneuvers  only  the 
second  aircraft. 

Set  if  the  same  sense  negative  of  this  resolution 
advisory  will  provide  sufficient  separation. 

Set  if  this  resolution  advisory  contains  a  "descend" 
that  is  changed  to  a  "don’t  climb." 

Index  into  PSEP  for  the  horizontal  resolution 
advisory  for  the  first  aircraft. 
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TABLE  10-2 


FIELD 

INDEX2 

INDEX3 

VALUE 

NXTADV 


RESOLUTION  ADVISORY  DATA  STRUCTURE 
(Concluded) 


DEFINITION 


Index  into  PSEP  corresponding  to  the  horizontal 
resolution  advisory  for  the  second  aircraft. 

Index  into  the  appropriate  vertical  level  of  PSEP. 

Will  be  set  to  indicate  the  relative  value  of  this 
resolution  advisory. 

Pointer  to  next  resolution  advisory. 
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TABLE  10-3 


RESOLUTION  ADVISORY  TRANSLATION  TABLE: 
ATARS  REPRESENTATION /CIR  REPRESENTATION 


RESOLUTION 

ATARS 

CIR  CODE 

ADVISORY 

CODE 

D  FIELD 

VSL  FIELD 

No  Res  Adv 

0 

0000000000 

00 

Null  Res  Adv 

6 

0000000000 

00 

HORIZONTAL 

Turn  Left  (TL) 

1 

1000000000 

00 

Turn  Right  (TR) 

2 

1010000000 

00 

Don't  Turn  Right 

(DTR) 

3 

1100000000 

00 

Don't  Turn  Left 

(DTL) 

4 

1 1 10000000 

00 

Don't  Turn  Left/ 
Don't  Turn  Right 

(DTL/DTR) 

5 

N/A 

VERTICAL 

Climb  (CL) 

1 

0001000000 

00 

Descend  (DES) 

2 

0001001000 

00 

Don't  Descend  (DDES) 

3 

0001100000 

00 

Don't  Climb  (DCL) 

4 

0001101000 

00 

Don't  Climb/ 

Don't  Descend  (DCL/DDES) 

5 

N/A 

Limit  Descent  2000ft/min 
(LIMDES) 

7 

0001111000 

11 

Limit  Climb  2000ft/min 
(LIMCL) 

8 

0001110000 

11 

Limit  Descent  lOOOft/min 
(LIMDES) 

9 

0001111000 

10 

Limit  Climb  lOOOft/min 
(LIMCL) 

10 

0001110000 

10 

Limit  Descent  500ft/min 
(LIMDES) 

11 

0001111000 

00 

Limit  Climb  500ft/min 
(LIMCL) 

12 

0001110000 

00 

*  For  double  dimension  advisories  the  CIR  code  is  the  logical  OR  of 
the  codes  for  the  separate  dimensions. 
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TABLE  10-4 


WHICH  AIRCRAFT  TO  MANEUVER  WHEN  NEITHER  IS  IN  FINAL  APPROACH  ZONE 


AIRCRAFT  1 


AIRCRAFT  2 

Controlled 

Equipped 

Controlled 

Unequipped 

Uncontrolled 

Equipped 

Uncontrol led 
Unequipped 

Controlled 

Equipped 

Both 

AC  2 

AC1* 

AC2 

Controlled 

Unequipped 

AC1 

Neither 

AC1 

Neither 

Uncontrolled 

Equipped 

AC2* 

AC  2 

Both 

AC  2 

Uncontrolled 

Unequipped 

AC1 

Neither 

AC1 

Neither 

*  Both  aircraft  will  be 

maneuvered  if 

PIFR  is  set 
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TABLE  10-5 


WHICH  AIRCRAFT  TO  MANEUVER  WHEN  AC2  IS  IN  FINAL  APPROACH  ZONE 

AIRCRAFT  1 


Controlled 

Controlled 

Uncontrolled 

Uncontrolled 

AIRCRAFT  2 

Equipped 

Unequipped 

Equipped 

Unequipped 

Controlled 

Equipped 

AC1 

AC2 

AC1 

AC2 

Controlled 

Unequipped 

AC1 

Neither 

AC1 

Neither 

Uncontrolled 

Equipped 

AC1 

AC2 

AC1 

AC2 

Uncontrolled 

Unequipped 

AC1 

Neither 

AC1 

Neither 

Rule  to  determine  which  aircraft  to  maneuver. 

If  one  of  the  aircraft  is  on  final  approach, 

1.  Give  resolution  advisories  to  the  aircraft  not  on  final 
approach  if  it  is  equipped. 


2.  Give  resolution  advisories  to  the  aircraft  on  final 
approach  if  the  other  aircraft  is  unequipped. 


vertical  dimension,  the  vertical  maneuvers  are  not  hardwired, 
but  are  computed  using  this  "eight  second  rule."  The  same  is 
not  done  when  one  aircraft  is  to  get  a  resolution  advisory, 
because  it  may  be  desirable  to  maneuver  one  aircraft  toward 
another  to  avoid  a  vertical  chase. 

One  of  the  criteria  used  to  evalute  a  resolution  advisory  is  the 
separation  that  resolution  advisory  is  expected  to  produce.  The 
predicted  separation  (PSEP)  is  determined  by  using  a  fast  time 
simulation  to  model  the  aircraft  responding  to  resolution 
advisories.  This  procedure  is  explained  in  Predicted  Separation 
Matrix  (Section  10.1).  This  model  is  also  used  to  determine 
whether  the  negative  of  a  resolution  advisory  provides 
sufficient  separation. 

Reference  to  the  negative  of  a  resolution  advisory  always  means 
the  negative  of  the  opposite  direction  advisory.  That  is,  the 
negative  of  a  "turn  left"  is  not  "don't  turn  left,"  but  "don't 
turn  right."  The  negative  of  "turn  right"  is  "don't  turn  left.” 
The  negative  of  "climb"  is  "don't  descend"  and  the  negative  of 
"descend"  is  "don't  climb." 

Once  the  list  of  possible  resolution  advisories  is  set  up  and 
the  PSEP  matrix  is  generated,  the  resolution  advisories  can  be 
evaluated.  The  evaluation  criteria  include  safety  and  predicted 
separation.  The  evaluation  process  is  described  in  Feature 
Evaluation  (Section  10.2). 

RER  logic  selects  positive  resolution  advisories  in  the  hori¬ 
zontal  or  vertical  dimension  then  modifies  those  resolution 
advisories  to  negative  as  a  special  case  of  the  same  sense 
positive  resolution  advisory.  Figure  10-2  shows  the  routine  to 
determine  if  the  negative  of  a  resolution  advisory  provides 
sufficient  separation.  If  negative  resolution  advisories 
provide  sufficient  separation,  the  NEGATIVE  flag  is  set  in  the 
resolution  advisory  data  structure. 

When  the  vertical  dimension  has  been  selected  for  resolution, 
negative  vertical  resolution  advisories  are  selected  if  the 
vertical  predicted  separation  at  the  time  a  pilot  responds  is 
greater  than  the  positive  resolution  advisory  altitude  separation 
(ASEP)  and  the  aircraft  will  not  converge  to  less  than  ASEP 
during  the  projection  interval.  If  both  aircraft  are  maneuvered, 
negative  vertical  advisories  are  explicitly  modeled.  This  is 
not  true  if  only  one  aircraft  is  maneuvered.  If  only  one  air¬ 
craft  is  maneuvered,  both  the  "climb"  and  "descend"  advisories 
will  be  examined.  If  the  advisory  will  maneuver  that  aircraft 
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FIGURE  10-2 

NEGATIVE  RESOLUTION  ADVISORY  DETERMINATION  ROUTINE 
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into  the  unmaneuvered  aircraft,  then  the  negative  of  that 
advisory  is  not  acceptable,  since  the  negative  advisory  would 
still  allow  the  aircraft  to  maneuver  into  the  unmaneuvered 
aircraft.  If  the  advisory  will  maneuver  the  aircraft  away  from 
the  unmaneuvered  aircraft,  check  the  separation  achieved  by  the 
positive  advisory.  If  the  positive  sense  of  the  advisory  will 
prevent  the  aircraft  from  coming  closer  than  ASEP,  then  the 
negative  is  acceptable,  since  the  negative  is  essentially  a 
level-off  advisory.  The  negative  is  acceptable  only  if  the 
unmaneuvered  aircraft  does  not  have  a  large  vertical  rate 
towards  the  maneuverd  aircraft.  When  the  horizontal  dimension 
has  been  selected  for  resolution,  negative  horizontal  resolution 
advisories  are  selected  if  the  horizontal  predicted  separation 
along  each  of  the  allowable  response  paths  is  greater  than  the 
positive  resolution  advisory  horizontal  miss  distance  threshold 
(MDTHSQ).  To  check  if  negative  horizontal  resolution  advisories 
give  sufficient  separation,  four  PSEP  values  must  be  examined  if 
both  aircraft  are  maneuvered,  and  two  PSEP  values  must  be 
examined  if  only  one  aircraft  is  maneuvered. 

For  both  aircraft  maneuvered,  the  predicted  separations  must  all 
be  greater  than  MDTHSQ  if  both  aircraft,  either  aircraft  or 
neither  aircraft  maneuvers.  For  example,  if  "turn  left'V'turn 
left"  is  the  advisory  set  being  examined,  then  the  PSEP  values 
for  "turn  left'V'turn  left,"  "turn  lef t'V'continue  straight," 
"continue  straight"/"turn  left"  and  "continue  straight"/ 

"continue  straight"  must  all  be  greater  than  MDTHSQ  if  the 
NEGATIVE  flag  is  to  be  set  indicating  a  "don't  turn  right'V'don ' t 
turn  right"  advisory  combination. 

If  only  one  aircraft  is  maneuvered,  check  the  PSEP  values  of  two 
boxes.  If  the  potential  advisory  to  aircraft  one  were  "turn 
left,"  then  check  the  PSEP  value  of  the  "turn  left"/"continue 
straight"  and  "continue  s traight'V'continue  straight"  advisories 
to  determine  if  a  "don't  turn  right"  would  be  a  sufficient 
advisory  to  aircraft  one. 

Double  dimension  advisories  are  not  checked  for  the  possibility 
of  giving  negative  advisories.  When  single  dimension  advisories 
are  checked  for  negatives  being  sufficient,  always  check  for 
positive  or  negative  advisories  to  both  aircraft  (assuming  both 
maneuvered).  Never  give  a  positive  advisory  to  one  aircraft  and 
a  negative  to  the  other,  except  for  the  one  case  where  the  air¬ 
craft  to  receive  a  "descend"  advisory  is  below  ATERN  feet  AGL. 
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If  any  resolution  advisory  would  descend  an  aircraft  that  is 
currently  below  ATERN  feet  AGL,  then  the  BELOWIOOO  flag  is  set, 
indicating  that  the  "descend"  should  be  changed  to  a  "don't 
climb." 

The  Hi,  VI,  H2,  and  V2  fields  of  the  selected  resolution  advisory 
should  be  modified,  if  necessary,  because  of  the  NEGATIVE  flag  or 
the  BELOWIOOO  flag. 

If  negative  vertical  resolution  advisories  are  selected  for  both 
aircraft,  VSL  resolution  advisories  are  evaluated  as  shown  in 
detail  in  Figure  10-3. 

The  desired  vertical  speed  limit  is  computed  based  on  the 
current  altitude  separation,  current  speeds,  expected  pilot 
delay  time,  and  desired  separation  at  the  projected  collision 
time.  Speed  limits  are  computed  for  each  aircraft  assuming  that 
there  is  no  change  in  the  direction  and  velocity  of  the  other 
aircraft.  To  receive  a  VSL,  an  aircraft  must  be  maneuvering 
vertically  faster  than  the  minimum  rate  ( MRATE )  and  the 
direction  of  the  aircraft's  current  vertical  velocity  must  be 
towards  the  other  aircraft. 

VSL's  are  computed  individually  for  each  aircraft  of  the  pair. 
Consequently,  only  one  or  both  may  receive  VSL's  or  different 
VSL's  may  be  given  to  each  one.  The  computed  VSL  is  rounded 
down  to  2000  ft/min,  1000  ft/min,  or  500  ft/min. 

If  a  VSL  resolution  advisory  is  selected,  it  is  assigned  to  the 
vertical  field  in  the  resolution  advisory  data  structure.  Other¬ 
wise,  a  negative  vertical  resolution  advisory  is  assigned. 

After  the  VSL  calculations  have  been  performed,  the  Domino 
Routine  may  be  performed.  The  domino  logic  projects  each  of  the 
maneuvered  aircraft  in  the  conflict  pair  as  responding  to  each 
of  the  potential  resolution  advisories.  The  results  of  the 
domino  logic  are  a  high  priority  feature  used  to  evaluate  the 
relative  desirability  of  resolution  advisories.  If  an  aircraft 
in  conflict  is  predicted  to  be  involved  in  another  conflict 
requiring  resolution  advisories  because  of  response  to  a  partic¬ 
ular  resolution  advisory,  then  that  resolution  advisory  is  not 
favored  above  the  other  resolution  advisories. 

After  all  of  the  resolution  advisories  have  been  evaluated,  the 
resolution  advisory  that  has  been  given  the  highest  value  is 
chosen.  If  there  are  two  resolution  advisories  with  the  same 
value,  the  last  feature  uses  the  predicted  separation  to  break 
the  tie. 
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FIGURE:  10-3 
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10.1  Predicted  Separation  Matrix  (PSEP) 


The  PSEP  matrix  contains  the  separations  that  two  conflicting 
aircraft  are  expected  to  achieve  by  obeying  resolution  advi¬ 
sories.  The  separations  are  computed  by  performing  a  fast  time 
simulation  and  modeling  the  performance  of  the  aircraft.  The 
separation  is  a  weighted  three  dimensional  (3-D)  slant  range; 
vertical  is  weighted  VWEGHT  to  1. 

The  PSEP  matrix  is  a  3x3x3  array  (see  Figure  10-4).  The  first 
dimension  corresponds  to  the  three  horizontal  resolution  advi¬ 
sories:  Turn  Left  (TL),  Continue  Straight  (CS),  and  Turn  Right 
(TR),  for  one  of  the  aircraft.  The  second  dimension  corresponds 
to  the  same  three  horizontal  resolution  advisories  for  the  other 
aircraft.  The  third  dimension  corresponds  to  the  three  levels 
of  vertical  resolution  advisories.  The  levels  of  vertical 
resolution  advisories  will  be  explained  in  more  detail  later. 

Because  of  the  values  needed  by  the  negative  resolution  advisory 
determination  logic  and  the  domino  logic,  predicted  separations 
for  all  nine  of  the  horizontal-advisor ies-only  level  would 
normally  be  computed.  The  nine  predicted  separations  can  be 
calculated  by  performing  six  projections.  Each  aircraft  is 
projected  as  turning  left,  turning  right  and  continuing  straight. 
Then  the  nine  combinations  are  formed  and  minimum  separations 
calculated. 

While  the  projected  paths  for  each  aircraft  are  being  computed, 
the  appropriate  positions  are  saved  in  the  Resolution  Advisory 
Projected  Position  (RAPP)  Table  for  the  domino  logic. 

To  save  from  having  to  compute  square  roots,  the  square  of  the 
slant  range  is  stored.  Slant  range  is  measured  in  nautical 
miles  and  is  stored  in  nmi^. 

Each  of  the  three  horizontal  resolution  advisories  for  one 
aircraft  combines  with  those  for  the  other  aircraft,  giving  a 
total  of  nine  combinations.  These  nine  combinations  model  all 
possible  horizontal  resolution  advisories.  A  pair  where  both 
aircraft  are  to  be  maneuvered  could  get  the  horizontal  resolution 
advisories  TR/TR,  TR/TL,  TL/TR  or  TL/TL.  When  only  the  first 
aircraft  is  to  be  maneuvered,  the  horizontal  resolution  advi¬ 
sories  TL/CS  and  TR/CS  are  considered.  Similarly,  when  only  the 
second  aircraft  is  to  be  maneuvered,  the  horizontal  resolution 
advisories  CS/TL  and  CS/TR  are  considered.  An  aircraft  getting 
only  vertical  resolution  advisories  could  be  treated  as  if  it 
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were  getting  a  "continue  straight".  An  aircraft  obeying  a 
negative  horizontal  resolution  advisory  is  also  modeled  as  if  it 
were  continuing  straight.  The  algorithm  to  model  horizontal 
maneuvers  is  presented  in  Table  10-6. 

All  nine  combinations  are  not  formed  when  one  or  both  of  the 
aircraft  already  have  resolution  advisories  in  their  conflict 
table  entries.  In  this  case,  only  one  or  two  projected  paths 
need  to  be  computed  to  fill  in  two  of  the  horizontal  advisory 
level  rows.  For  example,  assume  an  aircraft  has  a  positive 
"turn  left"  advisory  in  its  conflict  table  entry.  In  this  case, 
only  a  "turn  left"  projection  needs  to  be  modeled  to  be  used  in 
determing  PSEP  values  for  both  the  "turn  left"  and  "continue 
straight"  rows.  If  an  aircraft  has  a  negative  horizontal 
advisory,  "don't  turn  left,"  then  two  paths  must  be  modeled. 

These  are  the  "don't  turn  left"  path  used  for  the  "continue 
straight"  advisory  row  of  the  PSEP  matrix  and  the  "turn  right" 
path  for  the  "turn  right"  row. 

The  vertical  dimension  must  be  handled  differently.  It  would  be 
prohibitively  expensive  to  compute  all  possible  vertical  resolu¬ 
tion  advisories  and  to  combine  them  with  the  nine  pairs  of  hori¬ 
zontal  resolution  advisories.  Fortunately,  it  isn't  necessary 
to  compute  all  possible  vertical  resolution  advisories;  only  some 
of  them  are  sensible.  For  maneuvered-maneuvered  pairs,  the 
"eight  second  rule"  is  used  as  previously  described.  No  other 
vertical  resolution  advisories  need  to  be  considered.  For  an 
unmaneuvered-maneuvered  pair,  vertical  resolution  advisories 
don't  have  to  be  considered  for  the  unmaneuvered  aircraft,  but 
both  "climb"  and  "descend"  for  the  maneuvered  aircraft  must  be 
investigated. 

It  seems  best  to  handle  maneuvered-maneuvered  pairs  and 
unmaneuvered-maneuvered  pairs  separately.  The  three  levels  of 
vertical  resolution  advisories  will  mean  one  thing  when  both  of 
the  aircraft  are  maneuvered  and  something  different  when  one  of 
the  aircraft  is  unmaneuvered. 

For  pairs  where  both  aircraft  are  to  be  maneuvered,  level  one 
will  correspond  to  both  aircraft  being  projected  ahead  with 
their  current  vertical  rate.  Level  two  will  correspond  to  the 
vertical  resolution  advisories  picked  by  the  "eight  second 
rule,"  and  level  three  will  correspond  to  the  negative  of  these 
resolution  advisories.  Note  that  negative  vertical  resolution 
advisories  must  be  explictly  computed. 

For  pairs  where  only  one  of  the  aircraft  is  maneuvered,  level 
one  will  have  the  same  meaning  as  above.  Level  two  will 
correspond  to  the  maneuvered  aircraft  getting  a  "descend,"  and 
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TABLE  10-6 


ALGORITHM  TO  MODEL  MANEUVERS 


PARAMETERS 

VI  -  Velocity  of  aircraft  1 
V2  -  Velocity  of  aircraft  2 
g  -  Acceleration  due  to  gravity 
ZDF  -  Final  vertical  rate 

TURN  RATE 

W1  =  g*  TAN  (BANK  ANGLE!  /VI 
W2  =  g*  TAN  (BANK  ANGLE)  /V2 

CONSTANTS  FOR  MANEUVER  ALGORITHMS 

SA  =  SIN  (W*  TIME  INTERVAL) 

CA  =  COS  (W*  TIME  INTERVAL) 

A  =  (1.0  -  CA)  /W 

B  =  SA  /  W 

ACCEL  =  ACCELC*TIME  INTERVAL 
if  ZDF  .GT.  Zl) 

=  -ACCELD*T IME  INTERVAL 
if  ZDF  .LT.  ZD 

TO  ADVANCE  AIRCRAFT  THROUGH  DELAY 


TO  ADVANCE  AIRCRAFT  THROUGH  A  LEFT  TURN 

X'  =  X  -  (YD*A)  +  (XD*B) 

Y'  =  Y  +  (XD*A)  +  ( YD*B ) 

XD'  =  (XD*CA)  -  (YD*SA) 

YD'  =  ( XD*SA)  +  ( YD*CA) 

TO  ADVANCE  AIRCRAFT  THROUGH  A  RIGHT  TURN 

X'  =  X  +  ( YD*A)  +  ( XD*B ) 

Y'  =  Y  -  (XD*A)  +  ( YD*B ) 

XD'  =  (XD*CA)  +  (YD*SA) 

YD'  =  -(XD*SA)  +  (YD*CA) 

TO  ADVANCE  AIRCRAFT  DURING 
VERTICAL  ACCELERATION 

If  ABS(ZDF-ZD)  .GI.  ABS(ACCEL) 
then  ZD'  =  ZD  +  ACCEL 
else  ZD'  =  ZDF 

Z'  =  Z  +  ZD'  *  TIME  INTERVAL 


X'  =  X  +  XD*DELAYH 
Y'  =  Y  +  YD*DELAYH 
Z’  =  Z  +  ZD^DELAYV 
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TABLE  10-6 


ALGORITHM  TO  MODEL  MANEUVERS 
(Continued) 


RELATIVE  RANGE  AND  VELOCITY  (VERTICAL  WEIGHTED) 


RX  =  X2  -  XI 

RY  =  Y2  -  Y1 

RZ  =  (Z2  -  Z1)*VWEGHT 

VRX  =  XD2  -  XD1 

VRY  =  YD 2  -  YD1 

VRZ  =  (ZD2  -  ZD1)*VWEGHT 

VERTICAL  DOT  TEST 


DOT  =  RZ*VRZ 
HORIZONTAL  DOT  TEST 
DOT  =  RX*VRX  +  RY*VRY 

THREE  DIMENSIONAL  DOT  TEST  (VERTICAL  WEIGHTED) 

DOT  =  RX*VRX  +  RY*VRY  +  RZ*VRZ 
THREE  DIMENSIONAL  MISS  DISTANCE  (VERTICAL  WEIGHTED) 


MD2  =  ( RY*VRZ  -  RZ*VRY)2  +  (RZ*VRX  -  RX*VRZ)2  +  (RX*VRY  -  RY*VRX)2 

VRX2  +  VRY 2  +  VRZ2 

MD  =  SQRT  ( MD2) 

HORIZONTAL  MISS  DISTANCE 


MD2  =  ( RX*VRY  -  RY*VRX)2 
VRX2  +  VRY2 

MD  =  SQRT  ( MD2) 
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TABLE  10-6 


BANK  ANGLE 


TURN  ANGLE 


TIME  INTERVAL  - 


DELAY 


DELAYH1 , 
DELAYH2 


DELAYV1, 

DELAYV2 


PR 


LL 


UL 

where  PR 
VF 

XDF, YDF 
XS,  YS 
XF,  YF 
VS 


ALGORITHM  TO  MODEL  MANEUVERS 
(Concluded) 


System  parameter  (BANKA)  for  the  bank  angle  to  be 
modeled. 

System  parameter  (TURNA)  for  the  angle  that  the 
slower  aircraft  is  to  be  turned  through. 

System  parameter  (TIMINT)  for  the  time  interval  for 
each  iteration  of  the  algorithm  to  advance  the 
aircraft  through  a  maneuver. 

Predicted  uplink  delay  plus  pilot's  delay  in 
response  to  resolution  advisories. 

Predicted  delay  before  this  aircraft  responds  to 
horizontal  resolution  advisories.  Set  to  zero  if 
the  aircraft  presently  has  a  positive  resolution 
advisory  in  this  dimension,  otherwise,  set  to  DELAY. 

Predicted  delay  before  this  aircraft  responds  to 
vertical  resolution  advisories.  Set  to  zero  if  the 
aircraft  presently  has  a  positive  resolution 
advisory  in  this  dimension,  otherwise,  set  to  DELAY. 

XDF*( XS-XF )  +  YDF*( YS-YF) 

VF 

PR  +  Diameter  of  Turn  of  Slower  Aircraft 
VF 


PR/ (VF  -  VS) 

current  range  projected  onto  velocity  vector  of 
faster  aircraft 

-  velocity  of  faster  aircraft 
X,  Y  components  of  VF 
coordinates  of  slower  aircraft 
coordinates  of  faster  aircraft 
velocity  of  slower  aircraft. 
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level  three  will  correspond  to  a  "climb"  for  that  aircraft.  The 
unmaneuvered  aircraft  will  be  projected  ahead  with  current 
vertical  rate  for  all  three  levels.  Negative  vertical  resolution 
advisories  are  not  explictly  modeled.  The  definition  of  the 
three  vertical  levels  for  all  of  the  above  '■ases  is  provided  in 
Table  10-7. 

The  only  exception  to  the  above  rules  is  when  it  is  desired  to 
model  a  descent  for  an  aircraft  below  ATERN  feet  AGL.  In  this 
case,  model  a  "don't  climb"  instead. 

While  collecting  the  3-D  slant  range,  record  the  minimum  two 
dimensional  Horizontal  Miss  Distance  (HMD)  and  the  minimum 
Vertical  Miss  Distance  (VMD) .  The  3-D  closest  approach,  hori¬ 
zontal  closest  approach  and  vertical  closest  approach  may  occur 
at  different  times. 

The  Horizontal  Miss  Distance  (HMD)  array  is  a  3x3  matrix.  Each 
element  in  the  HMD  matrix  correlates  with  the  appropriate  element 
of  the  first  level  of  the  PSEP  matrix. 

The  Vertical  Miss  Distance  (VMD)  array  is  a  three  element  array. 
Each  element  correlates  with  the  one  element  in  each  level  of 
the  PSEP  matrix  that  models  vertical  only  resolution  advisories. 

To  generate  the  PSEP  matrix,  a  fast  time  simulation  is  performed. 
The  expected  response  of  the  aircraft  to  the  resolution  advisory 
is  modeled  and  the  minimum  separation  between  the  aircraft  is 
measured.  The  aircraft  are  modeled  to  maneuver  for  a  fixed  time 
interval,  MANTM.  MANTM  is  computed  for  each  encounter  as  a 
function  of  the  velocities  of  the  maneuvered  aircraft. 

When  one  of  the  aircraft  is  already  receiving  (in  its  conflict 
table  entry)  a  resolution  advisory,  the  fast  time  simulation  of 
that  aircraft's  projected  path  will  be  handled  slightly  differ¬ 
ent  ly. 

The  difference  is  that  the  aircraft  is  assumed  to  be  already 
maneuvering  in  response  to  the  resolution  advisory  in  the 
conflict  table  entry.  If  a  horizontal  advisory  "turn  left"  is 
in  the  conflict  table  entry  from  another  conflict,  then  the 
aircraft's  paths  when  modeling  "continue  straight"  and  "turn 
left"  are  exactly  the  same. 

In  computing  the  predicted  separation  between  two  aircraft  in 
response  to  a  resolution  advisory,  each  aircraft's  projected 
position  and  velocity  must  be  determined  at  intervals  along  its 


TABLE  10-7 


LEVEL  1: 

LEVEL  2: 

LEVEL  3: 

LEVEL  1: 

LEVEL  2: 

LEVEL  3: 


PSEP  VERTICAL  LEVELS 


COMMANDED-COMMANDED 


Project  both  aircraft  ahead  with  their  current  vertical 
rate. 

Pick  vertical  using  "eight  second  rule,"  project  each 
aircraft  ahead  following  positive  of  vertical  resolution 
advisory. 

Pick  vertical  using  "eight  second  rule,"  project  each 
aircraft  ahead  following  negative  vertical  resolution 
advisory. 


UNCOMMANDED-COMMANDED 

Project  both  aircraft  ahead  with  their  current  vertical 
rate. 

Descent  for  CMDED*,  project  UNCMDED  ahead  at  current 
vertical  rate. 

Climb  for  CMDED,  project  UNCMDED  ahead  at  current 
vertical  rate. 


*  CMDED  -  maneuvered  (commanded);  UNCMDED  -  unmaneuvered  (uncommanded) 


predicted  path.  As  these  predicted  positions  and  velocities  are 
determined,  certain  of  these  values  are  saved  in  the  Resolution 
Advisory  Projected  Position  (RAPP)  Table  (Figure  10-5)  to  be 
used  by  the  Domino  Routine  (see  Section  10.3).  The  RAPP  table  is 
initialized  to  all  zeroes  before  the  PSEP  projections  are  calcu¬ 
lated.  This  is  done  so  that  if  the  domino  logic  tries  to  use 
values  that  have  not  been  calculated,  this  condition  can  be  rec¬ 
ognized  and  the  projection  calculations  may  then  be  performed. 

MANTM  is  calculated  in  the  following  manner.  First,  a  vertical 
maneuver  time  (VMANTM)  is  calculated.  If  the  two  aircraft  are 
initially  converging  at  a  rate  greater  than  ZDTH,  VMANTM  is 
computed  to  be  the  time  required  for  the  two  aircraft  to  reach 
co-altitude.  If  the  aircraft  are  diverging,  or  converging  at  a 
rate  less  than  ZDTH,  VMANTM  is  set  to  zero. 

Next,  a  horizontal  maneuver  time  (HMANTM)  is  calculated 
according  to  the  following  procedure.  If  only  one  aircraft  is 
to  be  maneuvered,  HMANTM  is  initially  set  to  the  value  which 
will  model  the  maneuvered  aircraft  through  a  turn  angle  (TURNA). 
If  both  aircraft  are  to  be  maneuvered,  the  initial  value  of 
HMANTM  should  model  the  two  aircraft  through  a  combined  angle  of 
TURNA.  To  this  initial  value  of  HMANTM  should  be  added  the  value 
of  the  DELAY  parameter.  Next,  if  the  horizontal  speed  ratio 
between  the  two  aircraft  is  greater  than  2:1,  a  Lower  Limit  (LL) 
and  an  Upper  Limit  (UL)  are  applied  to  HMANTM.  These  are 
computed  according  to  the  formulas  in  Table  10-6.  The  lower 
limit  is  applied  to  HMANTM  only  if  the  slower  aircraft  is  to  be 
maneuvered . 

Finally,  MANTM  is  chosen  to  be  the  larger  of  VMANTM  and  HMANTM. 
The  absolute  lower  and  upper  limits  of  MTLL  and  MTUL  are  applied 
to  the  value  of  MANTM  selected.  The  value  of  MANTM  is  a  value 
for  the  total  projection  time  in  response  to  a  resolution  advi¬ 
sory.  That  is,  any  delay  time  is  included  in  MANTM  so  that  the 
normal  modeled  response  is  for  an  aircraft  to  continue  on  its 
present  course  for  DELAY  seconds  and  then  maneuver  for  (MANTM  - 
DELAY)  seconds.  However,  if  an  aircraft  has  already  received 
the  resolution  advisory  to  be  modeled  in  either  dimension,  no 
delay  is  assumed,  and  the  maneuver  is  modeled  for  the  entire 
duration  of  MANTM. 

For  some  geometries  the  aircraft  will  still  be  converging  at 
the  end  of  MANTM.  For  these  geometries,  the  measured  minimum 
separation  will  be  larger  than  the  true  closest  approach. 
Determine  if  two  aircraft  are  converging  by  applying  the  DOT 
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FIGURE  10-5 

RESOLUTION  ADVISORY  PROJECTED  POSITION  (RAPP)  TABLE 


test  shown  in  Table  10-6.  If  the  value  computed  for  DOT  is 
negative,  then  the  aircraft  are  converging.  The  3-D  DOT  test 
should  be  applied  when  generating  the  PSEP  matrix.  The  vertical 
and  horizontal  tests  should  be  applied  for  generating  the  VMD 
and  HMD  matrices.. 

The  VMD  matrix  is  used  for  determining  if  negative  resolution 
advisories  give  sufficient  separation.  Do  not  issue  negative 
vertical  resolution  advisories  that  will  allow  the  aircraft  to 
converge.  Set  any  entry  in  VMD  to  zero  if  the  vertical  DOT  test 
indicates  convergence.  Likewise,  if  the  three-dimensional  DOT 
test  shows  convergence  at  MANTM ,  then  PSEP  is  set  to  zero  if  the 
resolution  advisory  set  contains  a  horizontal  maneuver.  For 
vertical  maneuvers  only,  PSEP  is  calculated  in  this  instance  by 
the  three-dimensional  miss  distance  formula  given  in  Table  10-6. 
Similarly,  if  the  horizontal  DOT  test  shows  convergence  at  MANTM, 
then  HMD  is  computed  from  the  horizontal  miss  distance  formula 
for  the  center  element  of  the  HMD  matrix  (no  horizontal  maneu¬ 
vers)  or  set  to  zero  for  any  other  element  (at  least  one  hori¬ 
zontal  maneuver). 

10.2  Feature  Evaluation 


The  resolution  advisories  are  evaluated  by  applying  a  number  of 
sequential  tests.  The  outcome  of  the  tests  may  depend  on  the 
geometry  of  tha  encounter,  the  speeds  of  the  aircraft,  the 
predicted  separation  or  many  other  factors.  Table  10-8  shows 
these  tests  in  order  of  precedence.  Table  10-9  provides  the 
logic  for  the  resolution  advisory  compatibility  and  reinforcement 
checks . 

Tne  data  structures  are  general  enough  to  allow  an  efficient 
implementation  in  most  programming  languages.  Any  implementation 
should  be  flexible  enough  to  allow  new  tests  to  be  added  and  the 
list  reordered  without  a  major  redesign. 

In  one  possible  implementation,  the  tests  would  be  individual 
routines  that  would  operate  on  the  list  of  resolution  advisories. 
Each  test  would  have  a  weight  associated  with  it;  the  most  impor¬ 
tant  test  would  have  the  highest  weight.  These  weights  would  be 
stratified  so  that  the  weight  of  a  test  would  be  greater  than  the 
sum  of  the  weights  for  the  less  important  tests.  This  could  be 
accomplished  by  using  sequential  powers  of  two  for  the  weights. 

If  a  resolution  advisory  passed  a  test,  its  VALUE  field  would  be 
increased  by  the  weight  for  that  test.  The  resolution  advisory 
with  the  highest  number  in  its  VALUE  field  would  be  considered 
the  best  resolution  advisory. 
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TABLE  10-8 


RESOLUTION  ADVISORY  EVALUATION  CRITERIA 


DELIVERABLE  -  Favor  this  resolution  advisory  if  the  predicted  3-D 
separation  is  greater  than  or  equal  to  the  predicted  .eparation  for 
the  pair  if  no  resolution  advisories  were  given. 

DIMENSION  AVAILABLE  -  Favor  single  horizontal  (vertical)  resolution 
advisories  if  ACIDH  (ACIDV)  is  null  and  no  other  aircraft  is 
receiving  a  horizontal  (vertical)  advisory  because  of  this 
aircraft.  Favor  single  horizontal  (vertical)  resolution  advisories 
if  the  aircraft  is  already  receiving  this  advisory.  Do  not  favor 
single  horizontal  (vertical)  resolution  advisories  if  either  of  the 
aircraft  is  receiving  an  advisory  that  is  incompatible  with  this 
advisory  (Table  10-9). 

Favor  doubles  if  the  conditions  for  both  favor  horizontal  and  favor 
vertical  are  satisfied. 

NEITHER  DOMINO  -  Favor  this  resolution  advisory  if  neither  aircraft 
is  predicted  to  be  in  another  conflict  because  of  this  resolution 
advisory. 

ONE  DOMINO  -  Favor  this  resolution  advisory  if  only  one  aircraft  is 
predicted  to  be  in  another  conflict  because  of  this  resolution 
advisory. 

PSEP  SEP1  -  Favor  this  resolution  advisory  if  the  predicted  3-D 
separation  is  greater  than  SEP1 .  (Vertical  weighted). 

FAR  FROM  RADAR  -  Favor  single  vertical  advisories  if  either  of  the 
aircraft  is  further  than  RDISTR  from  the  radar  (i.e.,  SLREPS  .GT. 
RDISTR) . 

NEGATIVE  SUFFICES  -  Favor  if  advisory  satisfies  the  criteria  for 
negative  resolution  advisory. 

NEGATIVE  DOES  NOT  REVERSE  MANEUVER  -  Favor  if  advisory  is  negative, 
the  pilot  is  maneuvering  and  the  negative  advisory  will  not  force 
him  to  stop  that  maneuver.  Turn  sensing  and  vertical  rate  sensing 
are  used  to  detect  a  maneuver. 

BIGGEST  PSEP  FOR  NEGATIVE  -  Favor  the  advisory  giving  the  biggest 
predicted  separation  and  has  NEGATIVE  set. 
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TABLE  10-8 


RESOLUTION  ADVISORY  EVALUATION  CRITERIA 
(Continued) 


FAST  UNCMDED/SLOW  CMDED  -  Favor  double  resolution  advisories  for  a 
CMDED-UNCMDED  encounter  if  the  speed  ratio  of  the  UNCMDED  to  the  CMDED 
is  at  least  VRATIO,  the  UNCMDED  is  converging  with  a  vertical  rate  in 
excess  of  ZDTH,  and  the  track  crossing  angle  is  between  TXTH1  and  TXTH2 . 

UNCMDED  WITH  LARGE  VERTICAL  RATE  -  Favor  horizontal  and  double  reso¬ 
lution  advisories  if  the  UNCMDED  is  converging  in  altitude,  with  a 
vertical  rate  in  excess  of  ZDTH. 

NO  LEVEL  OFF  TIME  FOR  VERTICALS  -  Favor  horizontal  and  double 
resolution  advisories  if  the  aircraft  are  between  TV1  and  TV2  seconds 
from  vertical  crossing. 

DETERIORATION  -  Favor  double  resolution  advisories  if  the  pair  has 
satisfied  tne  deterioration  logic  criteria.  (PATH=1) 

AIRCRAFT  ON  FINAL  APPROACH  -  Favor  single  horizontal  resolution 
advisories  for  an  aircraft  in  the  Final  Approach  Zone  (FAZ  set)  with  a 
ground  speed  of  less  tnan  VFAST. 

PATH  DEPENDENT  -  Favor  single  resolution  advisories  for  initial 
resolution  advisory  selection  and  transition.  (PATH“0) 

PSEP  SEP2  -  Favor  resolution  advisories  where  predicted  3-D  separation 
is  greater  than  SEP2  (vertical  weighted.) 

COMPATIBLE  WITH  TURN  -  Favor  advisories  where  horizontal  part  of 
advisory  is  not  the  opposite  of  a  turn  sensed  by  the  tracker. 

BIG  VERTICAL  MISS  DISTANCE  -  Favor  vertical  and  double  resolution 
advisories  if  the  existing  vertical  miss  distance  is  at  least  ASEPV. 

BIG  HORIZONTAL  MISS  DISTANCE  -  Favor  horizontal  and  double  resolution 
advisories  if  the  square  of  the  projected  horizontal  miss  distance  is 
at  least  MDHSQ. 

SPEED  CHECK  -  Favor  vertical  and  double  advisories  if  either  maneuvered 
aircraft  has  a  speed  greater  than  VFAST.  Favor  horizontal  and  double 
resolution  advisories  if  all  maneuvered  aircraft  (one  or  both 
aircraft)  have  speeds  below  VSLOW. 
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TABLE  10-8 


RESOLUTION  ADVISORY  EVALUATION  CRITERIA 
(Concluded) 


REINFORCES  PRIOR  RESOLUTION  ADVISORIES  -  Favor  advisory  that  has  the 
same  sense  as  the  advisory  given  on  the  previous  scan.  A  double 
advisory  given  after  a  single  advisory  is  compatible  if  it  includes 
that  single  advisory  (see  Table  10-9). 

REINFORCES  TURN  -  Favor  advisory  when  horizontal  part  of  the  advisory 
reinforces  a  turn  sensed  by  the  tracker. 

BIGGEST  PSEP  -  For  all  resolution  advisories  (single  horizontal, 
single  vertical,  double)  favor  the  advisory  with  the  largest  predicted 
3-D  separation. 
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TABLE  10-9 

PREVIOUS  RESOLUTION  ADVISORY/NEW  RESOLUTION  ADVISORY  COMPATIBILITY  AND  REINFORCEMENT 

Compatibility 
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To  reduce  computation  time,  the  list  could  be  pruned  after  some 
of  the  tests.  For  example,  the  test  that  decides  whether  to 
favor  single  or  double  resolution  advisories  is  guaranteed  to 
cut  the  list  to  half  of  its  size,  if  all  of  the  previous  tests 
are  equal.  By  eliminating  all  of  the  resolution  advisories  that 
are  not  tied  with  the  highest  value,  the  amount  of  computer 
processing  time  could  be  reduced.  Whether  or  not  this  savings 
is  signficant  depends  on  the  implementation. 

Domino  logic  is  effectively  one  feature.  However,  two  flags  are 
controlled  by  the  outcome  of  tne  domino  checks.  The  most  desir¬ 
able  situation,  and  therefore  the  higher  priority  of  the  domino 
flags,  is  for  neither  aircraft  to  be  predicted  as  being  involved 
in  a  domino  conflict  because  of  the  subject  resolution  advi¬ 
sories.  The  next  priority  flag  is  set  if  only  one  aircraft  is 
predicted  to  be  in  a  domino  conflict  because  of  its  resolution 
advisory.  The  remaining  possibilities  are  that  both  aircraft 
are  predicted  to  be  in  a  domino  conflict  because  of  this  resolu¬ 
tion  advisory  and  domino  logic  is  not  performed  for  this  pair  of 
aircraft.  In  these  two  cases,  neither  of  the  domino  flags  is 
set . 

If  there  are  no  resolution  advisories  with  ooth  the  Deliverable 
and  Dimension  Available  Features  set,  then  call  the  Multi¬ 
aircraft  Resolution  Routine,  described  in  Section  9.5.  If  only 
one  resolution  advisory  pair  has  the  Dimension  Available  Feature 
set,  then  the  domino  logic  checks  would  not  be  performed. 

10.3  Domino  Routine 


Wnen  an  aircraft  is  given  a  resolution  maneuver,  it  is  possible, 
that  by  executing  tnat  maneuver,  the  aircraft  will  be  directed 
into  a  conflict  requiring  resolution  advisories  with  another 
aircraft.  This  type  of  conflict,  caused  by  a  resolution  maneu¬ 
ver,  is  called  a  domino  conflict.  If  tne  second  conflict  begins 
before  tne  first  conflict  is  resolved,  then  there  is  a  multi¬ 
aircraft  conflict.  It  is  always  desirable  to  avoid  domino 
created  multi-aircraft  conflicts,  if  at  all  possible.  A  way  to 
avoid  a  domino  caused  multi-aircraft  conflict  is  to  model  an 
aircraft's  response  to  a  resolution  maneuver,  and  determine  if  a 
conflict  requiring  resolution  advisories  is  created  with  another 
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aircraft  during  the  time  the  aircraft  is  responding  to  the 
resolution  advisory.  Then,  if  there  is  more  than  one  set  of 
acceptable  resolution  advisories  for  a  pair  of  aircraft,  the 
best  set  of  resolution  advisories  that  does  not  cause  a  domino 
multi-aircraft  conflict  should  be  the  set  of  resolution  advi¬ 
sories  chosen.  Logic  that  performs  the  checks  for  detecting  a 
domino  caused  multi-aircraft  conflict  is  called  the  domino  logic 
and  is  performed  by  the  Domino  Routine. 

The  Domino  Routine  is  called  by  the  RER  during  evaluation  of  the 
features.  Figure  10-1  shows  the  logical  placement  of  the  domino 
logic  in  RER.  The  feature  evaluation  logic  determines  if  the 
domino  logic  should  be  called.  There  is  one  case  when  the  RER 
logic  determines  that  domino  need  not  be  performed;  This  occurs 
if,  after  determining  the  status  of  the  Deliverable  and  Dimension 
Available  Features,  there  is  only  one  resolution  advisory 
remaining. 

Figure  10-6  is  the  description  of  the  Domino  Routine.  The  domino 
logic  must  determine  all  the  possible  resolution  advisories 
available  to  each  aircraft.  The  potential  resolution  advisories 
are  needed  by  the  Domino  Coarse  Screen  Routine  (Section  10.3)  to 
determine  the  extent  of  the  search  limits.  This  routine  selects 
all  aircraft  that  are  within  the  search  limits  and  creates  a 
Potential  Domino  Conflict  List  for  each  of  the  aircraft  requiring 
resolution  advisories. 

To  determine  if  a  given  resolution  advisory  will  cause  an  air¬ 
craft  to  come  in  conflict  with  another  aircraft,  the  aircraft's 
path  in  response  to  the  resolution  advisory  must  be  modeled. 

This  was  done  when  the  PSEP  calculations  were  performed.  The 
projected  positions  and  velocities  were  stored  in  the  Resolution 
Advisory  Projected  Position  (RAPP)  Table  (Figure  10-3). 

After  modeling  an  aircraft's  response  to  a  resolution  advisory, 
the  maneuvered  aircraft's  position  and  velocity  at  four  SCANTM 
intervals  after  the  maneuver  has  begun  are  compared  to  the 
linearly  projected  positions  and  velocities  of  unmaneuvered  air¬ 
craft  from  the  Potential  Domino  Conflict  List  using  a  shortened 
detection  logic.  (Any  aircraft  on  the  potential  domino  list 
receiving  a  resolution  advisory  will  be  modeled  as  responding  to 
that  resolution  advisory  with  no  response  delay).  Since  the  only 
concern  is  for  a  conflict  requiring  resolution  advisories  being 
created,  the  resolution  advisory  checks  are  the  only  checks  of 
the  detection  logic  performed.  If  a  domino  conflict  is  deter¬ 
mined  with  any  aircraft  on  the  Potential  Domino  Conflict  List, 
then  the  remainder  of  the  list  need  not  be  checked  for  another 
domino  conflict  for  the  same  resolution  advisory.  The  subject 
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resolution  advisory  is  flagged  as  causing  a  domino.  The  domino 
checks  then  begin  for  the  next  resolution  advisory. 


Figure  10-7  is  the  detailed  flow  chart  of  the  Domino  Routine. 

The  first  thing  done  in  the  domino  logic  is  to  determine  which 
aircraft  is  maneuvered.  This  can  be  done  by  examining  the 
CMDED-UNCMDED  and  tne  UNCMDED-CMDED  flag  of  the  first  potential 
resolution  advisory.  If  one  of  the  aircraft  is  not  maneuvered, 
then  the  appropriate  NOCMD  flag  is  set.  These  flags  are  used  in 
the  Domino  Coarse  Screen  Routine. 

The  resolution  advisory  flags  are  set  by  cycling  through  all  the 
potential  resolution  advisories.  The  potential  resolution  ad¬ 
visory  flags  are  shown  in  Table  10-10.  There  is  only  one  flag 
for  negative  horizontal  resolution  advisories,  since  a  "don't 
turn  left"  and  "don't  turn  right"  are  both  equivalent  to 
"continue  straight."  Also,  since  there  may  be  at  most  one  VSL 
resolution  advisory  per  aircraft,  there  need  be  only  one  flag, 
with  the  value  of  the  flag  indicating  the  speed  limit  rate. 

Any  resolution  advisories  in  an  aircraft's  conflict  table  entry 
do  not  have  to  explicitly  be  accounted  for,  since  these  advi¬ 
sories  are  accounted  for  in  the  modeled  paths  for  the  potential 
advisories.  Taat  is,  i f  an  aircraft  has  a  "turn  left"  in  its 
conflict  table  entry,  a  potential  resolution  advisory  for  that 
aircraft  will  be  "turn  left."  If  the  potential  resolution 
advisory  is  "don't  turn  right"  or  there  is  no  potential  hori¬ 
zontal  resolution  advisory,  then  that  aircraft's  "continue 
straight"  path  will  actually  be  projected  as  responding  to  the 
"turn  left."  In  either  case,  the  eitect  of  advisories  in  the 
conflict  table  is  taken  into  account. 

The  Domino  Coarse  Screen  Routine  (Figure  10-8)  determines  a  list 
of  potential  domino  conflict  aircraft  for  each  of  the  aircraft 
that  is  to  receive  a  resolution  advisory.  If  there  are  no  poten¬ 
tial  conflict  aircraft  for  the  first  aircraft,  the  routine 
branches  to  the  processing  of  the  second  aircraft.  Otherwise, 
call  the  Domino  Detection  Routine  for  the  first  aircraft.  The 
Domino  Detection  Routine  checks  each  potential  resolution 
advisory  for  causing  a  domino  conflict.  The  target  aircraft's 
projected  positions  and  velocities  in  response  to  the  potential 
resolution  advisory  have  been  determined.  These  positions  and 
velocities  are  then  paired  with  linear  projections  of  each 
aircraft  from  the  Potential  Domino  Conflict  List.  If  a  domino 
conflict  is  predicted,  the  remainder  of  the  aircraft  from  the 
Potential  Domino  Conflict  List  are  not  checked  against  the  same 
resolution  advisory. 


10-34 


w 


FIGURE  10-7 
DOMINO  ROUTINE 
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TABLE  10-10 


POTENTIAL  RESOLUTION  ADVISORY  FLAGS 


FLAG  NAME 

SETTINGS 

DEFINITION 

LEFT1 ,  LEFT2 

-1 

Domino  caused  by  left  turn 

0 

No  left  turn 

1 

Potential  left  turn 

RGHT1 ,  RGHT2 

-1 

Domino  caused  by  right  turn 

0 

No  right  turn 

1 

Potential  right  turn 

NLNR1,  NLNR2 

-1 

Domino  caused  by  don't  turn  left 
and/or  don't  turn  right 

0 

No  negative  horizontal  resolution  advisory 

1 

Potential  don't  turn  left 
and/or  don't  turn  right 

NOCMD1 ,  NOCMD2 

0 

At  least  one  resolution  advisory 

1 

No  potential  resolution  advisories 
for  this  aircraft 

CH,  CL2 

-1 

Domino  caused  by  climb 

0 

No  climb 

1 

Potential  climb 

DES1,  DES2 

-1 

Domino  caused  by  descend 

0 

No  descend 

1 

Potential  descend 

NCL1,  NCL2 

-1 

Domino  caused  by  don't  climb 

0 

No  don't  climb 

1 

Potential  don't  climb 

NDS1,  NDS2 

-1 

Domino  caused  by  don't  descend 

0 

No  don't  descend 

1 

Potential  don't  descend 
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TABLE  10-10 


POTENTIAL  RESOLUTION  ADVISORY  FLAGS 
(Concluded) 


FLAG  NAME  SETTINGS  DEFINITION 

VSL1,  VSL2  -1  Domino  caused  by  vertical  speed  limit 

0  No  potential  VSL 

1  Potential  limit  climb  to  500  fpm 

2  Potential  limit  climb  to  1,000  fpm 

3  Potential  limit  climb  to  2,000  fpm 

4  Potential  limit  descend  to  -500  fpm 

5  Potential  limit  descend  to  -1,000  fpm 

6  Potential  limit  descend  to  -2,000  fpm 


LTCL1 ,  LTCL2  -1  Domino  caused  by  left  turn,  climb 

0  No  left  turn,  climb 

1  Potential  left  turn,  climb 

RTCL1 ,  RTCL2  -1  Domino  caused  by  right  turn,  climb 

0  No  right,  turn,  climb 

1  Potential  right  turn,  climb 

LTDS1 ,  LTDS2  -1  Domino  caused  by  left  turn,  descend 

0  No  left  turn,  descend 

1  Potential  left  turn,  descend 

RTDS1,  RTDS2  -1  Domino  caused  by  right  turn,  descend 

0  No  right  turn,  descend 

1  Potential  right  turn,  descend 


The  suffix  1  or  2  denotes  the  first  or  second  aircraft  in  the  pair 
record. 
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FIGURE  104 

DOMINO  COARSE  SCREEN  ROUTINE  (RrrR  *  0>  F) 
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FIGURE  104 

DOMtNO  CO  AM*  SCREEN  ROUTINE  {Pat*  j  ol  7) 
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DOMINO  COARSE  SCREEN  ROUTINE  (Rago  JolF) 
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FIQUM 104 

DOMINO  COANSC  SCREEN  ROUTINE  (Pag*  4  ol  7) 
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FIGURE  104 

OOMfNO  COARSE  SCREEN  ROUTINE  (Pag*  S  of  T) 


FIGURE  104 

DOMINO  COARSE  SCREEN  ROUTINE  (Raft  S  o* 


i 

! 


10-43 


7A 


N 

- » 


Y 


FIGURE  104 

DOMINO  COARSE  SCREEN  ROUTINE  (Rap  7  of  7) 
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The  detection  checks  performed  are  only  those  checks  that 
determine  the  need  for  resolution  advisories.  If  the  resolution 
advisory  flag  is  set,  then  a  domino  conflict  is  declared.  A 
domino  conflict  is  indicated  by  setting  the  Potential  Resolution 
Advisory  flag  to  -1.  Each  one  of  the  potential  resolution  advi¬ 
sories  is  checked  for  causing  a  domino  conflict  before  going  to 
the  checks  for  the  second  aircraft.  The  checks  performed  on  the 
second  aircraft  of  the  pair  are  exactly  the  same  as  those  per¬ 
formed  on  the  first  aircraft. 

10.3.1  Domino  Coarse  Screen  Routine 


The  Domino  Coarse  Screen  Routine  creates  a  list  of  potential 
domino  conflict  aircraft  for  each  maneuvered  aircraft  of  the 
subject  conflict  pair.  This  is  done  by  determining  how  far  the 
maneuvered  aircraft  could  fly  in  response  to  any  of  the  resolu¬ 
tion  advisories,  and  adding  to  this  distance,  a  distance  that  is 
the  maximum  immediate  separation  threshold  distance  used  in 
search  of  conflicts  requiring  resolution  advisories.  To  deter¬ 
mine  the  area  the  maneuvered  aircraft  may  cover,  the  potential 
resolution  advisories  must  be  known.  The  flags  indicating  these 
resolution  advisories  (see  Table  10-10)  are  determined  by 
searching  through  the  linked  list  of  resolution  advisories.  All 
resolution  advisories  with  the  Deliverable  and  Dimension 
Available  Features  set  are  included. 

Figure  10-8  is  the  detailed  flow  chart  of  the  Domino  Coarse 
Screen  Routine.  Table  10-11  shows  the  equations  for  determining 
the  search  limits  to  oe  used  by  the  Domino  Coarse  Screen  Routine. 
The  determination  of  the  resolution  advisory  tau  thresholds  is 
shown  in  Table  10-12.  The  value  of  TLD  used  in  the  Domino  Coarse 
Screen  Routine  is  MANTM  +  DELAY  +  MAX  (TCMDH.TCMDV) . 

The  Domino  Coarse  Screen  Routine  performs  a  forward  and  backward 
search  along  the  X-list  or  EX-list.  The  distance  to  be  searched 
along  the  X-li9t  is  a  function  of  the  current  speed  and  heading 
of  the  subject  aircraft  and  the  potential  resolution  advisories. 
The  search  limits  are  also  a  function  of  the  subject  aircraft 
being  on  the  X-list  or  EX-list.  If  the  subject  aircraft  is  on 
the  X-list,  only  the  X-list  is  searched  for  potential  conflict 
aircraft.  If  the  subject  aircraft  is  on  the  EX-list,  the  EX-list 
i<j  searched  and  the  X-list  may  be  searched  if  the  aircraft  is 
close  to  the  altitude  limit  of  the  X-list  and  projected  to  be 
within  the  altitude  limits  of  the  X-list  within  TLD  seconds. 

After  determining  which  list  the  subject  aircraft  is  on,  the 
search  limits  along  that  list  must  be  computed.  To  compute  the 
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TABLE  10-11 


DETERMINATION  OF  DOMINO  COARSE  SCREEN  SEARCH  LIMITS 


Calculation  of  Search  Limits 


1st  dimension  of  RAPP  table  -  Resolution  maneuver 

2nd  dimension  of  RAPP  table  -  Projected  positions  and  4  lookahead 

times 


X  Search  Limit  Calculations 


X(l)'  =  X(l,l)  +  XD(1,1)  *  TCMDH 

If  there  is  no  positive  horizontal  resolution  advisory  for  this 
aircraft  in  its  conflict  table  entry: 

X(2) 1  -  X(l)'  +  XD(1,1)  *  (3*SCANTM  +  TCMDH) 

If  there  is  a  positive  horizontal  resolution  advisory  for  this 
aircraft  in  its  conflict  table  entry: 

X( 2) '  -  X( 1 , 2)  +  XD( 1 , 2)  *  TCMDH 
X(3) '  =  X(l, 3)  +  XD( 1 , 3)  *  TCMDH 
X(4) '  =  X( 1 ,4)  +  XD( 1 ,4)  *  TCMDH 

If  LEFT,  LTCL,  or  LTDS  flag  set: 

X(5) '  =  X(2,l)  +  XD ( 2 , 1 )  *  TCMDH 
X(6) 1  =  X(2,2)  +  XD(2,2)  *  TCMDH 
X( 7 ) *  =  X(2 , 3)  +  XD( 2 , 3)  *  TCMDH 
X(8) '  =  X(2,4)  +  XD(2,4)  *  TCMDH 


If  RGHT,  RTCL,  or  RTDS  flag  set: 

X(9) '  -  X(3, 1)  ♦  XD(3, 1)  *  TCMDH 
X(10)’  *  X(3,2)  +  XD(3, 2)  *  TCMDH 
X(ll)’  *  X(3,3)  +  XD(  3, 3)  *  TCMDH 
X(  12)  '  *  X(3,4)  +  XD(3,4)  *  TCMDH 

Use  only  computed  X' : 

XU  -  Max  (X(l)\  X(2)  ' , . . .  ,X(  12) '  )  +  RMAX 
XL  -  Min  (X(l)',  X( 2) ' , . . . ,X( 12) 1 )  -  RMAX 
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TABLE  10-11 


DETERMINATION  OF  DOMINO  COARSE  SCREEN  SEARCH  LIMITS 

(Concluded) 


Use  Table  10-12  Co  select  parameters  and: 

If  subject  aircraft  is  controlled  and  on  the  X-list,  do  for: 
RMAX  -  240  kts  *  (MANTM  +  DELAY  ♦  TCMDH)  ♦  RCMD2 

If  subject  aircraft  is  controlled  and  on  the  EX-list,  do  for: 
RMAX  -  600  kts  *  (MANTM  +  DELAY  +  TCMDH)  +  RCMD2 

If  subject  aircraft  is  uncontrolled,  do  for: 

RMAX  =  240  kts  *  (MANTM  +  DELAY  +  TCMDH)  +  RCMD2 

Y  Search  Limit  Calculations 

The  calculation  of  the  Y  direction  search  limits  is  exactly 
analagous  to  the  calculation  of  the  X  direction  search  limits. 

Altitude  Search  Limit  Calculations 

Z(l)'  ■  Z(l,l)  +  ZD( 1,1)  *  (TCMDV  +  3*SCANTM) 

If  CL,  LTCL  or  RTCL  flag  set: 

Z(2) 1  -  Z(2,l)  +  ZD(2,1)  *  (TCMDV  +  3*SCANTM) 

If  DES,  LTDS ,  or  RTDS  flag  set: 

Z(3) '  -  Z(3 , 1)  +  ZD(3,1)  *  (TCMDV  +  3*SCANTM) 

If  NCL,  NDS  or  VSL  flag  set: 

Z(4) '  -  Z(4,l)  ♦  ZD(4,1)  *  (TCMDV  +  3*SCANTM) 

Use  only  computed  Z': 

ZU  -  Max  (Z(l)',  Z(2) ' ,  Z(3)',  Z(4)')+  ZMAX 
ZU  -  Min  (Z(l)',  Z(2) ' ,  Z(3)',  Z(4)')+  ZMAX 

If  subject  aircraft  is  controlled,  do  for: 

ZMAX  -  1000  fpm  *  (MANTM  +  DELAY  +  TCMDV)  +  AF 

If  subject  aircraft  is  uncontrolled,  do  for: 

ZMAX  -  1000  fpm  *  (MANTM  +  DELAY  +  TCMDV)  +  AF 
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TABLE  10-12 


RESOLUTION  ADVISORY  THRESHOLDS  USED  IN  DOMINO  LOGIC 


AIRCRAFT  PAIR* 


TCMDH  & 

TCMDV  RCMD2  AF 


Controlled/Controlled 
1  a/c  in  area  type  4 
all  others 


38  sec  0.75  nmi  750  ft 

30  0.75  750 


Controlled/Uncontrolled 
1  a/c  in  area  type  4 
1  a/c  in  area  type  3 
all  others 


38  sec  1.0  nmi  750  ft 

30  1.0  750 

30  0.75  750 


Uncontrol led/Uncont rolled 

all  pairs  40  sec  0.0  nmi  750  ft 


*In  determining  the  detection  thresholds  for  the  Domino  Coarse 
Screen  Filter,  use  the  value  applicable  to  the  subject  aircraft  that 
results  in  the  maximum  search  area.  If  the  subject  aircraft  is 
controlled,  choose  the  values  from  controlled/uncontrolled 
thresholds  that  give  the  maximum  Domino  Coarse  Screen  search  area. 


For  the  Domino  Detection  logic,  use  the  values  applicable  to  the 
subject/object  aircraft  pair  being  checked  for  a  domino  conflict. 


search  limits,  the  resolution  advisory  tau  threshold  and 
immediate  range  parameters  must  be  chosen.  Table  10-12  is  used 
to  choose  Che  resolution  advisory  tau  threshold  and  immediate 
range  parameters  used  in  the  Domino  Coarse  Screen  Routine  and 
the  Domino  Detection  Routine. 

Table  10-11  shows  the  calculations  for  determining  the  domino 
coarse  screen  search  limits.  If  an  aircraft  is  flying  straight 
in  the  horizontal  dimension,  the  search  limits  are  linear  pro¬ 
jections  of  the  aircraft's  current  speed  in  the  X  and  Y  direc¬ 
tions.  However,  if  the  aircraft  is  turning  or  could  potentially 
be  turning,  then  adjustments  must  be  made  to  the  linear 
projection. 

The  module  that  performed  the  PSEP  calculations  also  saved 
projected  positions  and  velocities  in  response  to  potential 
resolution  advisories  in  the  RAPP  table.  To  calculate  the 
coarse  screen  limits,  a  TCMDH  projection  is  made  from  each  of 
the  points  along  the  response  path  in  the  RAPP  table.  There  may 
be  two  sets  of  projections,  if  the  resolution  advisory  time  for 
controlled/uncontrolled  encounters  is  different  from  the  time 
for  uncontrolled/uncontrolled  or  controlled/controlled 
encounters. 

Once  the  minimum  and  maximum  X  and  Y  projected  positions  have 
been  calculated,  a  buffer  distance  (RMAX)  must  be  added  to 
obtain  the  actual  X-list  (EX-list)  search  limits.  The  buffer  is 
the  distance  that  an  aircraft  going  the  maximum  speed  of  an 
aircraft  on  the  X-list  (EX-list)  can  travel  during  the 
resolution  advisory  response  projection  interval  (MANTM  +  DELAY) 
and  the  resolution  advisory  tau  time  (TCMDH),  plus  the  immediate 
separation  threshold  (RCMD2).  The  maximum  speeds  are  240  kts 
for  aircraft  on  the  X-list  and  600  kts  for  aircraft  on  the 
EX-list.  A  maximum  vertical  maneuver  rate  of  1000  ft/min  is 
assumed  for  aircraft  on  the  X-list  and  EX-list. 

The  altitude  limits  used  in  the  Domino  Coarse  Screen  Routine  are 
computed  similarly  to  the  horizontal  limits.  That  is,  the  maneu¬ 
vered  aircraft  is  projected  from  its  current  altitude  using  its 
current  altitude  rate  for  (MANTM  +  DELAY  +  TCMDV).  The  maneu¬ 
vered  aircraft  is  also  modeled  as  responding  to  any  computed 
maneuvers,  positive,  negative  or  VSL  that  appear  in  the  air¬ 
craft's  conflict  table  entry.  Then  the  maximum  and  minimum 
altitudes  are  determined  among  each  of  the  modeled  paths  and  an 
altitude  buffer  (ZMAX)  is  added  to  obtain  the  altitude  search 
limits  used  by  the  Domino  Coarse  Screen  Routine. 
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After  the  search  limits  have  been  calculated,  the  Domino  Coarse 
Screen  Routine  simply  searches  along  the  X-list  (EX-list) 
looking  for  aircraft  that  are  contained  in  the  X,  Y  and  Z  search 
limits.  Any  aircraft  within  these  bounds  are  added  to  the 
Potential  Domino  Conflict  List  for  the  subject  aircraft  (see 
Table  10-13). 

Any  aircraft  within  the  search  limits  that  are  already  in 
conflict  and  receiving  a  resolution  advisory  with  the  subject 
aircraft  are  not  added  to  the  Potential  Domino  Conflict  List. 

It  is  possible  for  an  aircraft  to  be  in  more  than  one  conflict 
on  a  scan.  If  this  is  the  case,  then  it  is  possible  to  compute 
a  list  of  potential  domino  conflict  aircraft  twice  on  the  same 
scan  for  a  particular  aircraft.  It  is  best  to  avoid  this  dupli¬ 
cate  processing  if  possible.  When  a  list  of  potential  domino 
conflict  aircraft  is  created  for  a  subject  aircraft,  a  pointer 
to  the  head  of  that  list  is  saved  in  the  pair  record.  Also  in 
the  pair  record  is  a  field  of  flags  indicating  which  maneuvers 
were  considered  in  the  determination  of  the  list.  If  an  aircraft 
goes  through  master  resolution  and  RER  a  second  time  on  the  same 
scan,  then  it  is  possible  that  the  same  Potential  Domino  Conflict 
List  may  be  used.  If  the  resolution  advisories  being  considered 
for  the  second  conflict  are  the  same  or  a  subset  of  the  resolu¬ 
tion  advisories  considered  for  the  first  conflict,  then  the  same 
list  of  potential  domino  conflict  aircraft  may  be  used.  The  only 
exception  is  that  the  other  aircraft  in  the  current  pair  may  be 
on  the  list  of  potential  domino  conflict  aircraft.  To  use  the 
same  list  of  potential  domino  conflict  aircraft,  set  the  appro¬ 
priate  INDX  parameter  in  this  pair  record  to  the  same  value  as 
the  INDX  parameter  for  the  subject  aircraft  in  the  previous  pair 
record. 


10.3.2  Domino  Detection  Routine 


The  remainder  of  the  domino  logic  consists  of  performing  the 
detection  checks  for  conflicts  requiring  resolution  advisories 
between  the  subject  aircraft  and  each  of  the  aircraft  on  the 
Potential  Domino  Conflict  List.  The  detection  checks  are 
performed  for  each  aircraft  on  the  Potential  Domino  Conflict 
List  or  until  a  conflict  is  found,  for  each  potential  maneuver 
for  the  subject  aircraft.  The  conflict  detection  parameters  are 
determined  according  to  the  rules  of  Table  10-12. 

To  minimise  the  number  of  times  the  Domino  Detection  Routine  is 
performed,  a  coarse  detection  check  is  made  first  to  determine 
the  need  for  performing  the  detailed  conflict  detection  at  each 
of  the  projected  points.  For  each  aircraft  on  the  Potential 
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TABLE  10-13 


POTENTIAL  DOMINO  CONFLICT  LIST  ENTRY 


FIELD  CONTENT 


INTRAC  -  Pointer  to  the  state  vector  for  this  potential  domino 
conflict  aircraft. 

CS1*,  -  Flag  for  no  horisontal  advisory  or  negative  horizontal 

CS2  advisory. 

CW1*,  -  Flag  for  no  vertical  advisory. 

CW2 

RGHT1*,  -  Flag  for  right  advisory. 

RGHT2 

LEFT1*,  -  Flag  for  left  advisory. 

LEFT2 

CLIMB1*,  -  Flag  for  climb  advisory. 

CLIMB2 

DESC1*,  -  Flag  for  descend  advisory. 

DESC2 

DCL1*,  -  Flag  for  don't  climb  advisory. 

DCL2 

DDES1*,  -  Flag  for  don't  descend  advisory. 

DDES2 

VSL1*,  -  Flag  for  VSL  advisory. 

VSL2 

XPRJ1,  -  Horizontal  projected  positions  for  this  aircraft. 
YPRJ1, 

XPRJ2, 

YPRJ2, 

XPRJ3, 

YPRJ3, 

XPRJA , 

YPRJ4 
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TABLE  10-13 


POTENTIAL  DOMINO  CONFLICT  LIST  ENTRY 
(Concluded) 


FIELD  CONTENT 

XDPRJ1 ,  -  Horizontal  projected  velocities  for  this  aircraft. 

YDPRJ1, 

XDPRJ2, 

YDPRJ2, 

XDPRJ3, 

YDPRJ3, 

XDPRJ4 , 

YDPRJ4 

ZPRJ1 ,  -  Vertical  projected  positions  for  this  aircraft. 

ZPRJ2, 

ZPRJ3, 

ZPRJ4 

ZDPRJ  -  Vertical  projected  velocity  for  this  aircraft. 

NXTINTR1,  -  Pointer  to  the  next  aircraft  in  the  list  of  potential 

NXTINTR2  domino  conflict  aircraft. 


*  0  -  This  advisory  for  the  subject  aircraft  has  not  been  checked 

for  causing  a  domino  conflict  with  this  aircraft. 

1  -  This  advisory  to  the  subject  aircraft  causes  a  domino 

conflict  with  this  aircraft. 

2  -  This  advisory  for  the  subject  aircraft  has  been  checked  and 

it  does  not  cause  a  domino  conflict  with  this  aircraft. 
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Domino  Conflict  List,  the  values  in  Table  10-14  are  calculated 
and  the  tests  in  Figure  10-9  are  performed.  First,  it  is 
determined  if  the  two  aircraft  will  be  in  conflict  in  the 
vertical  dimension  at  any  time  during  the  projected  maneuver 
interval.  If  a  conflict  in  the  vertical  dimension  is  not  poss¬ 
ible  during  the  maneuver  interval,  then  the  detection  checks  do 
not  have  to  be  performed  for  this  potential  domino  conflict  air¬ 
craft.  Otherwise,  a  coarse  check  in  the  horizontal  dimension  is 
performed.  This  check  bypasses  the  detection  checks  if  the 
aircraft  are  diverging  and  presently  separated  by  more  than  the 
immediate  range  threshold  for  a  conflict.  However,  if  the 
potential  domino  conflict  aircraft  is  receiving  a  positive  hori¬ 
zontal  resolution  advisory,  or  the  potential  resolution  maneuver 
to  the  subject  aircraft  is  a  positive  horizontal  resolution 
advisory,  then  the  horizontal  coarse  detection  check  is  not 
performed. 

The  detection  checks  performed  to  determine  a  conflict  are  just 
the  resolution  advisory  detection  checks  of  Section  7.1.1. 

The  Domino  Coarse  Detection  Routine  (Figure  10-9)  should  not  be 
confused  with  the  Domino  Coarse  Screen  Routine.  The  Domino 
Coarse  Screen  Routine  generates  a  list  of  aircraft  which  are  in 
the  vicinity  of  the  pair  of  aircraft  in  conflict.  The  coarse 
detection  checks  are  a  way  to  reduce  the  detection  computations 
needed  to  determine  conflicts  between  aircraft  on  the  Potential 
Domino  Conflict  List  and  a  subject  aircraft  from  the  conflict 
pair. 

The  checks  for  determining  the  need  for  resolution  advisories 
requires  the  computation  of  tau  values  and  immediate  range 
values.  The  Domino  Detection  Routine  must  compute  these  values 
at  four  points  along  the  projected  path  of  each  potential  domino 
conflict  aircraft  paired  with  an  aircraft  from  the  subject  pair. 
In  addition,  it  is  possible  to  repeat  the  same  calculations 
twice  between  the  same  two  aircraft.  For  example,  if  a  maneu¬ 
vered  aircraft  may  receive  either  a  "turn  left"  or  "turn  right" 
advisory,  then  the  domino  logic  would  compute  the  same  vertical 
taus  and  separations  against  a  particular  aircraft  when  checking 
each  horizontal  advisory  for  causing  a  conflict.  The  number  of 
computations  could  be  reduced  by  remembering  the  outcome  of  the 
linear  projection  checks  between  the  two  aircraft.  The  data 
structure  for  the  potential  domino  conflict  aircraft  list  con¬ 
tains  fields  to  remember  the  outcome  of  the  linear  projection 
checks. 


10-53 


TABLE  10-14 


DOMINO  COARSE  DETECTION  ROUTINE  CALCULATIONS 

21,  ZD1  -  Altitute  and  altitude  velocity  of  subject  aircraft  at 
projection  time  (TEN  +  3*SCANTM)  from  the  RAPP  table. 

Z2,  ZD2  -  The  (TEN  ♦  3*SCANTM)  projected  altitude  and  altitude 
velocity  of  the  aircraft  from  the  potential  domino 
conflict  list. 

XI,  Y1  -  Horizontal  position  and  velocity  components  of  subject 

XD1,  YD1  aircraft  at  projection  time  (TEN  +  3*SCANTM)  from  the 
RAPP  table. 

X2,  Y2  -  The  (TEN  +  3*SCANTM)  projected  horizontal  position 

XD2,  YD2  and  velocity  components  of  the  aircraft  from  the 
potential  domino  conflict  list. 


VRZ  ’ 

IV  ' 

ALT  ' 

DOT  '  Equations  described  in  Figure  7-2 

DSQ  ' 

TH  ' 

RANGE 2  1 
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FIGURE  IM 

DOMINO  COARSE  DETECTION  ROUTINE 
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Another  savings  of  computation  time  can  be  achieved  by 
performing  the  linear  detection  checks  at  the  earliest  time  of 
data  in  the  RAPP  table  (TEN  +  3*SCANTM)  and  increasing  the  tau 
threshold  to  include  all  of  the  projection  time  of  the  RAPP 
table  (TEN  +  6*SCANTM).  Also,  the  immediate  range  test  may  be 
approximated  by  computing  the  range  at  time  (TEN  +  3*SCANTM)  and 
then  comparing  this  value  to  the  threshold  value  and  determining 
if  the  aircraft  are  diverging  or  converging.  Table  10-14  shows 
the  computations  necessary  to  perform  the  coarse  detection 
checks . 

The  altitude  velocity  used  for  the  aircraft  from  the  Potential 
Domino  Conflict  List  is  the  aircraft's  current  altitude  velocity 
unless  that  aircraft  is  in  a  conflict  and  has  a  resolution 
advisory.  If  a  vertical  advisory  appears  in  a  conflict  table 
entry  for  that  aircraft,  then  a  nominal  vertical  velocity  is 
used  if  the  sense  of  the  advisory  differs  from  the  aircraft's 
current  velocity.  For  example,  if  an  aircraft  has  a  "don’t 
climb"  advisory  and  a  positive  vertical  velocity,  then  use  a 
nominal  level  (zero)  vertical  velocity. 

If  an  aircraft  on  the  Potential  Domino  Conflict  List  is  receiving 
a  positive  horizontal  resolution  advisory,  then  model  a  response 
path  for  that  aircraft  in  order  to  perform  the  horizontal  portion 
of  the  conflict  detection  checks.  The  projection  will  be  at  the 
aircrafts  current  speed  and  heading  if  it  is  receiving  a  negative 
horizontal  resolution  advisory  or  no  horizontal  resolution 
advisory. 


j 
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11.  CONTROLLER  ALERT  PROCESSING 


Controller  alert  processing  generates  a  Controller  Alert  Message 
which  has  three  types  of  data  generated  at  different  times. 
Generation  of  the  first  two  types  of  data  is  described  below. 
Generation  of  the  third  type  of  data  is  one  of  the  functions  of 
the  Data  Link  Message  Construction  Task,  discussed  in  Section  14 

1.  Conflict  Resolution  Data  -  Alerts  controller  to  a 
potential  conflict  and  provides  ATARS  resolution  advisories 

2.  Resolution  Notification  Data  -  Informs  the  controller 
that  the  aircraft  have  received  resolution  advisories. 

3.  Avoidance  Alert  Data  -  Informs  the  controller  that  a 
controlled  aircraft  has  received  a  terrain,  obstacle,  or 
restricted  airspace  alert. 

A  Controller  Alert  Message  with  conflict  resolution  data 
contains  the  initial  maneuvers  selected  for  the  aircraft  pair 
which  is  displayed  to  the  controller  but  not  displayed  to  the 
aircraft.  A  Controller  Alert  Message  with  resolution  notifi¬ 
cation  data  contains  resolution  advisories  displayed  to  the 
controller  after  receipt  by  the  aircraft.  Normally,  the  first 
message  is  generated  when  the  ICAFLG  is  set  or  a  controller 
alert  has  been  requested  for  3  out  of  5  of  the  previous  ATARS 
processing  scans  and  the  second  message  is  displayed  when  ATARS 
receives  confirmation  that  the  aircraft  have  accepted  the 
resolution  advisories. 

Within  one  Controller  Alert  Message  for  a  pair,  the  delivery 
status  field  (DEL)  is  set  for  the  pair.  When  a  pair  that  is 
controlled/uncontrolled  is  initially  recognized,  DEL  is  set  to 
001  and  ATARS  resolution  data  is  computed  for  the  uncontrolled 
aircraft.  No  resolution  data  in  computed  for  the  controlled 
aircraft.  After  confirmation  that  the  resolution  advisory  has 
been  accepted  by  the  uncontrolled  aircraft,  DEL  is  set  to  Oil 
for  both  aircraft  even  though  no  resolution  advisory  has  been 
computed  or  delivered  for  the  controlled  aircraft.  After 
confirmation  is  received  that  a  resolution  advisory  has  been 
accepted  by  the  controlled  aircraft,  the  Controller  Alert 
Message  will  display  the  accepted  resolution  advisory. 

The  Controller  Alert  Message  applies  to  a  pair  of  aircraft.  A 
separate  message  is  generated  for  each  pair.  If  one  aircraft  of 
a  pair  is  involved  in  a  multiple  aircraft  conflict,  several 
messages  pertaining  to  a  single  aircraft  will  be  delivered. 
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Three  data  structures  are  used  for  controller  alert  processing. 


1.  Controller  Alert  List  Buffer  -  A  temporary  list  passed 
in,  read,  and  cleared  in  controller  alert  processing.  Each 
entry  on  the  list  contains  the  ID's  of  the  aircraft,  ICAFLG 
and  the  sector  ID  of  the  pair  giving  rise  to  the  controller 
alert. 

2.  Controller  Alert  List  -  A  permanent  list  created  from 
the  Controller  Alert  List  Buffer  during  controller  alert 
processing.  This  list  contains  the  ID's  of  the  aircraft, 
the  time  of  the  most  recent  controller  alert  request,  the 
horizontal  and  vertical  maneuvers  selected  for  the  aircraft 
pair,  and  the  sector  ID's  of  the  aircraft.  Table  11-1 
lists  the  logical  content  of  the  Controller  Alert  List. 

3.  Controller  Alert  Message  -  A  temporary  data  structure 
created  each  time  a  new  message  is  sent  to  the  controller. 
Table  11-2  lists  the  logical  content  of  a  Controller  Alert 
Message.  External  transmission  and  screen  formatting  is 
handled  outside  the  ATARS  software. 

Controller  alert  processing  is  conceptually  divided  into  three 
functions.  The  first  function  processes  aircraft  pairs  and 
generates  data  used  for  the  controller  alert.  The  second 
function  reads  data  from  the  aircraft  CIR  and  generates  data 
used  for  the  controller  notice.  The  third  function  processes 
the  data  and  sends  the  message  to  the  ATC  facility.  In  practice 
however,  each  function  is  not  neatly  compartmentalized  into  its 
own  routine  due  to  the  timing  constraints  imposed  by  Sector 
Oriented  Task  Sequencing  (Figure  3-1).  Figures  11-1,  11-2,  and 
11-3  provide  the  detailed  flow  charts  of  controller  alert 
process ing. 

As  shown  in  these  flow  charts,  the  controller  alert  processing 
functions  are  divided  by  task  and  routine  as  described  below: 

1.  Controller  Alert  (Conflict  Resolution  Data)  Task  - 
Processes  aircraft  pairs  on  the  Controller  Alert  List 
Buffer  and  initalizes  or  updates  entries  on  the  Controller 
Alert  List.  After  the  pair  bypasses  or  completes  a  timing 
delay,  it  goes  to  alert  status  and  conflict  resolution  data 
is  generated  for  a  Controller  Alert  Message  (function  one 
and  three). 

2.  Update  Controller  Alert  List  Routine  -  Processes  CIR 
data  to  update  the  Controller  Alert  List.  After  pair 
records  are  updated  from  downlinked  CIR  data,  they  are 
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TABLE  11-1 


FIELD 

ACID1 

ACID2 

ALTIM1 

ALT I M2 

CHMAN1, 

CVMAN1 

CHMAN2 , 
CVMAN2 

WINSTR 

STATUS 

CALS ID 


LOGICAL  CONTENT  OF  CONTROLLER  ALERT  LIST 


CONTENT 


Identifier  of  aircraft  1  of  the  pair  in  conflict. 

Identifier  of  aircraft  2  of  the  pair  in  conflict. 

Most  recent  time  of  a  controller  alert  request  for 
aircraft  1. 

Most  recent  time  of  a  controller  alert  request  for 
aircraft  2. 

Horizontal  and  vertical  maneuvers  for  aircraft  1. 


Horizontal  and  vertical  maneuvers  for  aircraft  2. 


Bit  string  variable  used  for  timing  the  update  or 
deletion  of  the  pair  from  the  Controller  Alert  List. 

Variable  used  for  maintaining  the  status  of  a  pair  on 
the  Controller  Alert  List.  The  pair  status  may  be 
initial,  alert,  or  final. 

Variable  used  for  maintaining  the  current  sector  ID 
(position)  of  the  aircraft  pair. 
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TABLE  11-2 


LOGICAL  CONTENT  OP  CONTROLLER  ALERT  MESSAGE* 


FIELD  CONTENT 

ACID1  -  Identifier  of  aircraft  1  of  the  pair  in  conflict. 

ACID2  -  Identifier  of  aircraft  2  of  the  pair  in  conflict. 

CS1  -  Control  status  (con trolled /uncontrol led)  and  the 

equipment  of  aircraft  1  as  known  to  the  ATARS 
system. 

CS2  -  Control  status  (controlled/uncontrolled)  and  the 

equipment  of  aircraft  2  as  known  to  the  ATARS 
system. 

HMAN1 ,VMAN1  -  Horizontal/vertical  maneuvers  for  aircraft  1. 

HMAN2.VMAN2  -  Horizontal/vertical  maneuvers  for  aircraft  2. 

DELI  -  Delivery  status  of  maneuvers  for  aircraft  1. 

DEL2  -  Delivery  status  of  maneuvers  for  aircraft  2. 

Vl  -  Indicates  possible  need  for  controller  voice 

communications  to  aircraft  1. 

V2  -  Indicates  possible  need  for  controller  voice 

communications  to  aircraft  2. 


AMTYP  -  Alert  message  type  indicating  a  controller  alert  or 

that  an  alert  has  been  sent  to  aircraft  1  (terrain, 
obstacle,  or  restricted  airspace  alert). 


*  See  Reference  8. 
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figure  11*1 
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passed  to  this  routine.  Resolution  data  from  the  pair 
records  is  used  to  initialize  or  update  entries  on  the 
Controller  Alert  List,  and  the  pair  status  becomes  final 
(function  two). 

3.  Controller  Alert  (Resolution  Notification)  Task  - 
Processes  all  pairs  on  the  Controller  Alert  List  for  the 
appropriate  sector.  It  deletes  pairs  that  aren't  updated 
after  both  aircraft  have  missed  update  for  two  scans.  It 
sends  conflict  resolution  data  for  pairs  in  alert  status 
and  sends  resolution  notices  for  pairs  in  final  status 
(functions  one  and  three). 


i 
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12.  MULTI-SITE  RESOLUTION  PROCESSING 


This  section  describes  intersite  ATARS  communication  and  the 
protocol  involved.  Communication  among  sites  is  required  when 
aircraft  are  in  conflict  in  regions  serviced  by  more  than  one 
ATARS.  The  protocol  involves  the  messages  exchanged  and  house 
keeping  actions  required  to  maintain  an  accurate  data  base. 

When  aircraft  are  in  regions  covered  by  adjacent  sites,  these 
sites  coordinate  to  assure  continuity  and  non-duplication  of 
resolution  service.  Two  means  of  coordination  are  provided  in 
this  design.  Conflict  tables  are  exhanged  using  ground 
communication  lines,  where  a  network  connection  exists  between 
two  sites.  This  is  described  in  Section  12.1.  Elsewhere,  the 
coordination  is  performed  through  the  aircraft  transponders 
using  the  Conflict  Indicator  Register  (CIR)  required  for  all 
ATARS-equipped  aircraft.  This  register  also  enables  coordi¬ 
nation  between  ATARS  and  BCAS.  This  coordination  is  described 
in  Section  12.2.  See  Table  5-2  for  a  description  of  the  infor¬ 
mation  contained  in  the  CIR. 

The  ATARS  site  responsible  for  a  conflict  is  indicated  by  the 
ATS ID  variable  in  the  conflict  table  pair  record.  A  detailed 
description  of  this  variable  is  given  in  Table  12-1. 

Section  12.3  describes  special  communications  between  connected 
sites  which  are  required  only  when  a  site  fails  to  receive  CIR 
data  for  an  aircraft  in  the  CIR  Buffer.  Section  12.4  describes 
the  procedure  to  delete  an  aircraft  state  vector  from  storage. 
Section  12.5  describes  management  tasks  for  conflict  tables 
involved  in  a  seam  between  sites. 

12.1  Conflict  Table  Exchange  Using  Ground  Lines 

The  primary  means  of  multi-site  coordination  uses  ground  lines, 
wherever  these  are  installed.  This  method  provides  ATARS  a 
complete  and  current  copy  of  the  neighboring  site's  conflict 
tables  so  that  seam  conflicts  may  be  recognized  and  correctly 
resolved. 

Whenever  the  Seam  Pair  Task  (Section  7.2)  recognizes  a  conflict 
containing  an  aircraft  in  a  seam,  it  places  the  pair  on  the 
Delayed  Resolution  List.  The  Request  and  Process  Remote  Conflict 
Tables  Task  (Figure  12-1)  initiates  a  message  through  the  DABS 
ground  line  network  to  all  neighboring  sites  covering  any  part 
of  the  conflict.  The  request  (see  Table  12-2)  identifies  the 
pair  of  aircraft  that  own-site  intends  to  resolve.  This  task 
then  becomes  dormant  until  a  reply  is  received.  The  sector 
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TABLE  12-1 


CONTENT  OF  ATS ID  VARIABLE  IN  PAIR  RECORD 


FIELD 

NO.  BITS 

MEANING 

ID 

4 

Identification  of  ATARS  site  responsible 
for  this  pair. 

Handoff 

1 

Pair  is  in  handoff  status  when  set.  ID 
field  above  designates  site  previously 
responsible. 

External 

1 

Indicates  other  ATARS  site  with  same  ID  as 
own  site.  Only  used  in  backup  mode  when 
center  zone  is  adjacent  to  such  a  site. 
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TABLE  12-2 


FORMAT  OF  CONFLICT  TABLE  EXCHANGE  MESSAGES 
(USING  GROUND  COMMUNICATION  LINES) 


1.  Request  (may  be  sent  to  several  sites  with  NID  changed  as 
appropriate) 


FIELD 

MEANING 

OWN  ID 

Own  ATARS  ID 

NID 

Neighboring  site  ATARS  ID 

AC1TYP 

Aircraft  1  Type  (DABS  or  ATCRBS) 

AC1ID 

DABS  Address;  or  position  data  a 
number  if  ATCRBS 

AC2TYP 

Aircraft  2  Type 

AC2  ID 

Aircraft  ID  same  as  AC1ID 

REPLY 

( 1  bit ) 

Do/Don't  Send  Reply 

DEL  (1 

bit ) 

Delete  Pair  Record 

Reply 

FIELD 

MEANING 

OWN  ID 

Requesting  site  ATARS  ID 

NID 

Replying  site  ATARS  ID 

AClTYP 

,  AC2TYP, 

Same  as  request 

AC1ID, 

AC2ID 

Same  as  request 

NTABL 

Number  of  conflict  tables  (0, 

CTl 

First  conflict  table  if  any 

CT2 

Second  conflict  table  if  any 

1,  or  2) 
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processing  executive  has  the  responsibility  to  terminate  the 
task  prematurely  when  it  is  time  to  begin  the  Master  Resolution 
(Delayed)  Task.  The  neighboring  site  returns  a  message  to  the 
requesting  site  containing  zero,  one,  or  two  conflict  tables 
(see  Table  12-2).  Two  tables  would  be  returned  if  the  site  had 
the  two  subject  aircraft  in  unconnected  conflicts.  This  routine 
merges  these  conflict  tables,  so  that  requests  on  subsequent 
scans  should  always  receive  one  conflict  table  in  the  reply. 

When  the  requesting  site  receives  each  reply  from  a  neighboring 
site,  it  executes  the  Conflict  Table  Reply  Processing  Routine 
(Figure  12-2).  This  routine  updates,  adds  or  deletes  pair 
records  whose  ATSID  is  or  was  set  to  the  neighboring  site's  ID. 
This  routine  must  be  executed  even  if  the  reply  contains  no 
conflict  table,  as  pair  records  may  exist  in  own-site's  copy  of 
the  conflict  table.  However,  if  no  ground  line  connection 
exists,  oi  if  the  reply  is  not  received  by  the  time  the  Sector 
Processing  Executive  determines  processing  must  continue,  this 
routine  is  not  executed.  In  this  case  the  latest  CIR  processing 
update  (Section  5.3)  gives  information  on  the  neighboring  sites' 
actions. 

When  a  site  receives  a  request  for  conflict  tables,  that  site 
executes  the  Incoming  Seam  Pair  Request  Processing  ind  Reply 
Task  (Figure  12-3).  This  task  generates  the  reply  message  and 
sets  ATSID  in  the  pair  record  to  the  requesting  site's  ID, 
unless  the  pair  is  already  being  resolved  by  own-site. 

Any  ATCRBS  aircraft  which  appears  in  an  exchanged  conflict  table 
must  be  subjected  to  a  correlation  procedure  by  the  receiving 
site  when  that  ATCRBS  aircraft  first  appears.  It  is  necessary 
to  perform  this  correlation  procedure  to  prevent  two  adjacent 
sites  from  creating  separate  conflict  table  entries  for  the  same 
aircraft. 

The  site  which  originates  the  conflict  table  with  the  ATCRBS 
aircraft  will  identify  that  aircraft  with  a  unique  ID  on  the 
first  and  all  subsequent  exchanges.  The  receiving  sites  need 
perform  the  correlation  only  once.  Thereafter,  a  cross- 
reference  will  link  that  ID  to  the  local  state  vector.  The  ID 
selected  for  this  purpose  must  be  one  that  cannot  be  duplicated 
by  another  remote  site.  For  this  reason,  it  is  suggested  that 
an  ID  be  constructed  by  a  concatenation  of  the  local  CTS  slot 
number  with  the  ID  of  the  local  site. 

This  cross-reference  will  contain  entries  for  all  ATCRBS  aircraft 
within  the  local  ATARS  mask  which  the  local  ATARS  function 
currently  has  in  conflict  tables  that  are  being  exchanged.  It 
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is  identified  as  CREFX  and  is  entirely  unrelated  to  the  CREFA 
cross-reference  used  in  report  processing.  Each  entry  in  CREFX 
consists  of  an  ATCRBS  ID  (created  by  either  a  local  or  remote 
ATARS)  and  a  pointer  to  the  state  vector  of  this  aircraft  in  the 
local  CTS.  For  ATCRBS  aircraft,  the  pointer  in  the  state  vector 
designated  ATCREF  will  be  used  as  a  return  pointer  to  this  entry 
in  CREFX.  Only  those  ATCRBS  aircraft  which  are  in  seam  conflict 
tables  will  have  an  entry  in  CREFX  and  have  a  non-null  value  for 
ATCREF. 

ID's  of  ATCRBS  aircraft  may  be  added  to  CREFX  in  two  ways. 

First,  when  a  conflict  table  is  received  from  a  remote  site  with 
an  ATCRBS  ID  which  is  not  already  in  CREFX,  that  ID  is  added. 
Second,  when  performing  CIR  processing  and  an  ATCRBS  aircraft 
which  is  not  in  CREFX  appears  in  a  downlinked  conflict  table,  a 
new  ID  is  created  and  added. 

The  ATCRBS  correlation  procedure  described  in  Section  5.3  is 
used.  It  consists  of  a  proximity  test  plus  ATCRBS  code  check. 

An  ATCRBS  report  is  always  transmitted  with  the  conflict  table 
when  an  ATCRBS  aircraft  is  in  the  conflict  table.  This  report 
consists  only  of  the  current  predicted  range,  azimuth,  and 
altitude  coordinates  and  the  ATCRBS  code.  In  the  ATCRBS  correla¬ 
tion,  the  remote  range  and  azimuth  are  converted  to  local  coordi¬ 
nates.  The  correlation  procedure  consists  of  using  the  X-list 
in  much  the  same  way  as  in  coarse  screening.  The  proper  location 
of  the  ATCRBS  report  in  the  X-list  is  found.  A  search  along  the 
X-list  in  both  directions  to  X  limits  is  made.  All  aircraft 
encountered  are  tested  against  Y  and  Z  limits  and  against  the 
ATCRBS  code.  The  correlation  procedure  is  successful  if  one  and 
only  one  ATCRBS  aircraft  is  found  satisfying  the  requirements. 

Correlation  should  be  attempted  every  cycle  until  a  successful 
correlation  occurs.  Hence,  the  failure  to  correlate  on  the 
first  appearance  of  a  new  ATCRBS  aircraft  is  not  fatal.  An 
entry  in  REMA  is  created  and  used  until  a  successful  correlation 
occurs. 

Two  other  new  data  structures,  besides  CREFX,  are  used  to 
provide  cross-referencing  during  the  processing  of  exchanged 
conflict  tables.  These  are  the  remote  DABS  (REMD)  and  remote 
ATCRBS  (REMA)  lists.  A  single  entry  on  one  of  these  lists 
applies  to  a  single  aircraft.  The  entry  is  a  subset  of  the 
aircraft  state  vector.  An  entry  on  these  lists  is  accessed 
either  directly  with  a  pointer  or  through  a  cross-reference  with 
an  aircraft  ID  (either  a  DABS  code  or  the  same  type  of  ATCRBS  ID 
used  with  CREFX). 
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It  will  often  happen  that  a  remote  ATARS  will  pass  a  seam 
conflict  table  that  includes  one  or  more  aircraft  which  are  not 
within  the  local  data  base.  The  local  ATARS  must  retain  these 
aircraft  in  the  conflict  tables  as  place-keepers  so  that,  when 
the  local  ATARS  is  required  to  perform  conflict  resolution  on  an 
aircraft  in  this  conflict  table  which  is  in  the  local  data  base, 
an  accurate  conflict  table  exists.  The  local  ATARS  is  not 
required  to  process  these  remote  aircraft  in  any  other  way. 

Hence,  the  entries  in  REMD  and  REMA  serve  essentially  as 
abbreviated  state  vectors. 

The  REMFLG  in  the  conflict  table  entry  registers  the  current 
remote  status  of  the  aircraft  to  which  that  entry  refers.  If 
REMFLG  is  set,  the  ACID  field  in  that  conflict  table  entry  points 
to  an  entry  in  REMD  or  REMA  instead  of  to  a  state  vector.  REMFLG 
is  not  transmitted  in  the  conflict  table  message  because  each 
ATARS  must  determine  for  itself  if  a  particular  aircraft  is 
remote. 

The  local  ATARS  determines  the  value  to  be  used  for  NAC  in  the 
conflict  table  head  of  a  received  conflict  table  by  counting  the 
number  of  conflict  table  entries.  This  field  is  not  transmitted 
in  the  conflict  table  exchange  message. 

12.2  Conflict  Table  Exchange  Using  CIR 

Since  all  ATARS-equipped  aircraft  have  a  CIR,  the  information 
contained  therein  is  always  used  to  update  and  exchange  conflict 
information.  This  data  exchange  is  primary  for  purposes  of 
coordination  with  BCAS,  and  for  confirming  that  own  ATARS 
resolution  advisories  were  received  (see  Section  5.3  for  both  of 
these);  and  for  determining  the  current  multi-site  seam  status 
of  the  aircraft  in  Geographical  Processing  Routine  (see  Section 
6.3).  When  ground  communication  lines  are  installed  and 
operating,  the  CIR  exchange  is  secondary  for  multi-site  ATARS. 
When  no  ground  lines  are  available,  the  CIR  becomes  the  primary 
method  of  coordination. 

All  resolution  advisories  sent  to  an  aircraft  are  stored  in  the 
CIR  (unless  rejected  for  incompatibility).  All  CIR  rows  are 
read  every  scan  by  every  ATARS  site  providing  service  to  the 
aircraft.  In  this  way,  one  site  can  learn  of  another  site's 
action  affecting  aircraft  in  the  seam.  Although  the  conflict 
information  exchanged  this  way  (see  Table  5-2)  is  less  detailed 
than  that  exchanged  over  ground  lines,  it  contains  sufficient 
information  to  ensure  selection  of  compatible  advisories. 
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Every  CIR  row  contains  a  field  (the  B/C  field)  indicating  the 
system  responsible  for  that  row.  Table  12-3  lists  the  values 
for  this  field.  A  BCAS  row  may  only  be  updated  by  BCAS,  and  an 
ATARS  row  only  by  the  same  ATARS  site  which  created  it.  The 
ATARS  sites  are  indicated  by  their  4  bit  ID. 

Normally,  the  ATARS  site  originally  resolving  a  conflict  con¬ 
tinues  the  resolution  to  the  conflict  end.  This  is  true  even 
when  the  pair  flies  into  a  seam  area  where  another  site  would 
normally  have  higher  priority.  However,  when  an  aircraft  leaves 
a  site's  service  area,  that  site  must  release  its  CIR  rows  for 
pairs  involving  this  aircraft.  This  action  is  called  a  "handoff" 
in  the  flow  charts,  but  is  unrelated  to  ATC  handoffs.  The  site 
releasing  its  CIR  rows  sends  a  message  to  any  neighboring  sites 
indicated  in  the  aircraft  GEOG  variable,  if  ground  lines  are 
available.  This  action  gives  the  neighboring  sites  an  opportun¬ 
ity  to  assume  responsibility  for  the  pair  immediately.  If  the 
ground  line  is  not  available,  a  neighboring  site  learns  of  the 
pair's  availability  when  it  reads  the  CIR. 

12.3  Remote  CIR  Data  Exchange 

When  own-s ite  fails  to  read  an  aircraft's  CIR  data,  it  requests 
this  data  from  another  site  (the  "receiving  site")  connected  by 
a  ground  communication  line.  This  request  is  totally  independent 
of  the  conflict  table  exchange  described  above;  it  is  made  even 
when  the  subject  aircraft  is  not  known  to  be  in  any  conflict. 

This  start/stop  request  is  an  ATARS-ATARS  message  passed  through 
the  Remote  Site  Coordination  Buffer.  The  message  format  is 
shown  in  Table  12-4. 

The  ATARS  receiving  this  request  executes  the  Process  Request 
for  CIR  Data  Routine,  shown  in  Figure  12-4.  If  the  aircraft  is 
in  the  seam  of  the  requesting  and  receiving  sites'  coverage,  the 
receiving  site's  DABS  should  already  be  enabled  to  read  the 
aircraft's  CIR.  If  not,  the  sensor  is  told  to  do  so,  and  to 
borrow  the  requesting  site's  ATARS  ID  for  this  aircraft.  Any 
messages  the  requesting  site  could  not  uplink  are  also  sent  to 
the  sensor. 

After  the  receiving  site  reads  down  the  aircraft  CIR  contents, 
the  CIR  Processing  Task  (see  Section  5.3)  sends  the  data  to  the 
requesting  site.  If  the  request  specified  that  only  one  scan  of 
data  was  desired,  as  indicated  by  the  one  scan  flag  (OSCFL),  the 
CIR  Processing  Task  calls  the  Stop  Remote  CIR  Data  Routine,  shown 
in  Figure  12-5.  Otherwise,  CIR  data  is  returned  each  scan  until 
the  requesting  site  sends  a  message  to  stop  remote  CIR  data,  the 
receipt  of  which  executes  the  same  routine.  This  routine  stops 
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TABLE  12-3 


RESPONSIBILITY 

VALUE  OF  B/C  FIELD 
1  1  1 

1  1  0 

1  0  1 

1  0  0 

0  1  1 

0  1  0 

0  0  1 

0  0  0 


FIELD  IN  CIR  ROW 

MEANING 

BCAS  responsible 
Spare 

ATARS  row,  handoff  condition 
ATARS  site  1000  responsible 
ATARS  site  0100  responsible 
ATARS  site  0010  responsible 
ATARS  site  0001  responsible 
No  resolution  established 


TABLE  12-4 


FORMAT  OF  START/STOP  REMOTE  CLR  DATA  MESSAGE 


FIELD 

BITS 

MEANING 

OWNID 

4 

ATARS  ID  of  site  requesting  data 

NID 

4 

Neighboring  site  ATARS  ID 

ACID 

24 

DABS  Address  of  subject  aircraft 

START/STOP 

1 

Request  to  start  or  stop  sending  data 

OSCFL 

1 

Only  one  scan  of  CIR  Data  is  requested 
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the  sensor  from  collecting  CIR  data,  unless  the  receiving  site's 
ATARS  is  also  providing  service  to  the  aircraft. 

12.4  State  Vector  Deletion 


This  task  (Figure  12-6)  processes  aircraft  on  the  Deletion  List 
and  removes  the  aircraft  state  vector  from  CTS  if  appropriate. 
(This  list  should  not  be  confused  with  the  Resolution  Deletion 
Encounter  List. )  An  aircraft  may  be  put  onto  the  Deletion  List 
in  three  ways. 

1.  By  the  Track  Update  Routine  if  DABS  has  lost 
surveillance  contact  with  the  aircraft. 

2.  By  the  Track  Update  Routine  if  missed  reports  have 
caused  the  ATARS  track  firmness  to  drop  below  the  level 
needed  to  qualify  for  ATARS  service. 

3.  By  the  Report  Processing  Task  if  the  track  is  seen  to 
have  left  the  ATARS/domino  service  mask. 

If  the  aircraft  is  still  contained  in  a  conflict  table,  a  REMA 
or  REMD  entry  is  created  at  the  time  the  state  vector  is  deleted. 
If  ATARS  has  some  unfinished  business  with  the  aircraft  such  as 
a  handoff  message  to  be  sent,  state  vector  deletion  is  delayed. 

12.5  Conflict  Table  Seam  Status 


Each  conflict  table  contains  a  seam  flag.  This  flag  helps  the 
Seam  Pair  Task  recognize  pairs  involved  with  more  than  one  ATARS 
site  and  delay  resolution  until  coordination  is  performed. 

The  Conflict  Table  Seam  Addition  Task,  shown  in  Figure  12-7,  is 
performed  after  the  Geographical  Processing  Routine  updates  each 
aircraft's  GEOG  variable.  This  task  searches  every  non-seam 
conflict  table.  If  any  aircraft  is  found  whose  GEOG  indicates 
coverage  by  a  site  other  than  own  (other  than  own  or  failed 
site,  when  own-site  is  the  master  site),  the  seam  flag  is  set. 

The  Conflict  Table  Seam  Deletion  Task,  shown  in  Figure  12-8,  is 
performed  after  delayed  resolution,  pair  removal,  and  state 
vector  deletion.  This  task  searches  all  conflict  tables  in 
memory  which  have  the  seam  flag  set.  If  any  are  found  which  are 
entirely  interior  to  own-site  and  not  involved  with  a  seam,  the 
seam  flag  is  reset.  If  any  are  found  which  are  entirely  exter¬ 
ior,  that  is,  only  contain  remote  aircraft,  the  conflict  table 
is  deleted.  These  conditions  can  come  about  when  seam  pairs  are 
deleted,  and  the  only  remaining  pairs  in  the  conflict  are  all 
interior  or  all  exterior. 
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13.  CONFLICT  PAIR  REMOVAL 


The  Conflict  Pair  Removal  Task  ensures  that  each  conflict 
resolved  by  the  local  site  is  closed  out  in  the  proper  manner 
when  the  conflict  is  over  and  that  conflict  data  stored  in  the 
pair  records  is  deleted  when  it  is  no  longer  needed.  The  main 
flow  chart  for  the  Conflict  Pair  Removal  Task  is  given  in  Figure 
13-1  and  is  described  in  Section  13.1.  The  deletion  of  all  pair 
records  is  handled  by  the  Pair  Record  Deletion  Routine,  which  is 
described  in  Section  13.2.  This  routine  is  called  from  the 
Conflict  Pair  Removal  Taste,  as  well  as  from  several  other  tasks. 

13.1  Conflict  Pair  Removal  (Main  Task) 


The  Conflict  Pair  Removal  Task  examines  each  pair  record 
associated  with  the  current  sector.  If  a  pair  record  has 
already  been  processed  on  this  scan  (PWISF  set),  then  no  further 
processing  takes  place.  If  processing  has  not  already  occurred, 
then  this  task  checks  for  two  basic  conditions:  (1)  an  aircraft 
has  just  flown  out  of  the  coverage  area  of  the  local  site,  and 
(2)  the  local  site  has  assumed  responsibility  for  the  pair,  but 
is  no  longer  calling  for  resolution  advisories. 

When  an  aircraft  is  discovered  to  have  flown  out  of  coverage  of 
the  local  site,  all  resolution  advisory  information  pertaining 
to  that  aircraft  can  be  cleared  out  of  the  conflict  table.  This 
may  mean  that  a  pair  record  involving  that  aircraft  can  be 
deleted  immediately. 

For  a  conflict  where  the  local  site  had  responsibility,  but  is 
no  longer  calling  for  resolution  advisories,  the  following  logic 
is  performed:  First,  the  sector  ID  is  updated  for  the  pair. 

The  Update  Sector  ID  Routine  is  described  in  Section  5.3. 5.  If 
the  local  site  is  attempting  to  uplink  null  advisories  or  handoff 
messages,  the  pair  record  is  left  with  no  further  change  so  that 
this  effort  may  continue.  Likewise,  if  positive  resolution 
advisories  were  previously  selected  and  they  have  not  been 
uplinked  for  the  minimum  time  period,  then  the  pair  record  is 
also  left  without  further  change.  If  the  local  site  is  no  longer 
detecting  a  conflict  solely  because  one  aircraft  flew  out  of  the 
coverage  area  of  the  local  site  (into  an  area  not  covered  by  an 
adjacent  site),  and  if  the  aircraft  remaining  in  coverage  is 
equipped  with  BCAS,  then  the  SEND  flag  for  the  BCAS  aircraft  is 
reset,  and  no  further  resolution  advisories  of  any  kind  are 
uplinked  for  the  conflict.  This  allows  either  the  existing 
advisories  to  time  out  or  BCAS  to  take  over  responsibility  for 
resolving  the  conflict.  In  all  other  cases  where  the  local  site 
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had  responsibility,  null  resolution  advisories  are  placed  in  the 
conflict  table  for  subsequent  uplink  to  one  or  both  aircraft. 

In  some  instances,  a  pair  record  may  be  found  where  the  local 
site  has  assumed  responsibility,  initial  resolution  advisories 
have  not  yet  been  selected,  and  PWISF  is  not  set.  This  implies 
that  the  2-out-of-3  rule  for  initial  resolution  advisories  has 
not  been  satisfied  and  that  the  detection  logic  is  not  calling 
for  resolution  on  this  scan.  In  this  case,  the  Conflict  Pair 
Removal  Task  implements  a  part  of  the  2-out-of-3  logic  by  incre¬ 
menting  POSCMD  and  deleting  the  pair  record  if  POSCMD  has  reached 
zero. 

13.2  Deleting  a  Pair  Record 

The  process  of  deleting  a  pair  record  when  a  pair  which  was 
previously  in  conflict  finally  clears  the  conflict  requires 
special  attention,  for  it  is  possible  that  a  multi-aircraft 
conflict  table  may  split  into  two  separate  conflict  tables.  It 
is  then  necessary  to  determine  which  aircraft  belong  in  each 
conflict  table. 

Once  it  has  been  determined  that  a  pair  has  cleared  the 
conflict,  that  pair  record  is  deleted  and  the  conflict  table 
entries  for  one  or  both  aircraft  may  be  deleted  from  the  conflict 
table.  The  resultant  conflict  table  is  still  a  single  structural 
item,  even  though  it  may  consist  of  two  logically  independent 
conflict  tables.  A  temporary  linked  list  of  aircraft  pair  ID's 
is  created  by  extracting  all  remaining  pair  ID's  from  the  pair 
list  of  the  subject  conflict  table.  The  process  of  building  up 
the  residual  conflict  table(s)  begins  by  considering  the  current 
conflict  table  head  to  be  the  table  head  for  the  first  new 
conflict  table  and  by  automatically  assigning  the  first  conflict 
table  entry  to  this  table.  All  aircraft  in  pairwise  conflict 
with  this  aircraft  must  go  in  the  first  table  also. 

Call  the  list  of  pair  ID's  list  A  and  create  another  list  of 
aircraft  ID's  called  list  B.  This  list  is  a  list  of  all  aircraft 
which  have  been  identified  for  inclusion  in  the  first  conflict 
table.  A  third  list,  list  C,  is  a  list  of  all  pairs  which  belong 
to  the  first  conflict  table. 

A  pointer  to  an  entry  on  list  B  gives  the  first  aircraft  for 
which  a  scan  for  pair  conflicts  involving  that  aircraft  has  not 
yet  been  made  through  list  A. 
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The  ID  of  the  aircraft  in  the  first  conflict  table  entry  is 
added  to  list  B.  List  A  is  scanned  for  pairs  involving  this 
aircraft.  The  ID's  of  the  second  aircraft  in  these  pairs  are 
placed  on  list  B.  These  pairs  are  then  removed  from  list  A  and 
placed  on  list  C.  Next,  the  pointer  is  moved  down  list  B  to 
the  next  ID.  The  process  of  scanning  list  A  is  repeated.  If 
list  A  is  exhausted  before  the  pointer  rea  is  the  end  of  list 
B,  there  has  been  no  split  of  the  conflict  table.  If  the  pointer 
reaches  the  bottom  of  list  B  first,  there  has  been  a  split.  All 
aircraft  on  list  B  and  all  pairs  on  list  C  belong  to  the  first 
conflict  table  and  all  remaining  aircraft  and  the  pairs  on  list 
A  belong  to  the  second  conflict  table.  (With  the  breakup  of  a 
single  pair  only,  there  can  be  at  most  two  residual  conflict 
tables. ) 

The  detailed  flow  chart  for  deleting  a  pair  record  is  given  in 
Figure  13-2.  Once  the  pair  record  has  been  deleted,  the  NCON 
field  in  the  conflict  table  entry  of  each  aircraft  in  the  pair 
is  reduced  by  one. 

If  NCON  is  not  equal  to  zero,  then  the  conflict  table  entry 
should  not  be  deleted.  In  this  case,  the  intermediate  maneuver 
table  should  be  checked.  If  the  pair  record  being  deleted  is 
causing  a  resolution  advisory,  then  delete  the  resolution 
advisory  from  the  intermediate  maneuver  table,  decrement  MULTH 
or  MULTV,  and  set  HMAN  or  VMAN  to  the  highest  priority  of  toe 
remaining  resolution  advisories,  or  null  if  there  are  no 
resolution  advisories  in  that  dimension.  Section  9.7  describes 
the  manner  in  which  the  resolution  advisory  is  chosen  for  the 
conflict  table  entry. 

If  the  NCON  field  of  either  of  the  aircraft's  conflict  table 
entries  has  gone  to  zero,  that  aircraft  is  involved  in  no  other 
conflict  pair,  and  its  conflict  table  entry  is  completely 
deleted.  If  REMFLG  was  set  in  the  conflict  table  entry,  then 
the  remote  list  entry  for  the  aircraft  can  be  deleted. 

Otherwise,  the  CTPTR  and  CTE  fields  in  the  aircraft's  state 
vector  are  reset  to  null. 
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FIGURE  13-2 

PAIR  RECORD  DELETION  ROUTINE 


14.  DATA  LINK  MESSAGE  CONSTRUCTION 


The  Data  Link  Message  Construction  Task  generates  all  messages 
required  for  each  aircraft.  Three  types  of  messages  may  be 
generated  (one  type  for  conflicts,  and  two  types  where  no 
conflict  exists).  First,  if  the  aircraft  is  in  conflict,  any 
Resolution,  Threat,  or  Proximity  Advisory  Messages  required  are 
generated.  Second,  if  the  aircraft  is  a  new  entry  in  the  ATARS 
data  base,  an  Own  Message  is  generated,  and  third,  if  the 
aircraft  is  near  the  ground,  an  obstacle,  or  in  a  restricted 
airspace,  an  alert  message  is  generated  and  a  duplicate  Con¬ 
troller  Alert  Message  is  sent  to  the  ATC  facility. 

14.1  Conflict  Messages 

All  conflict  messages  are  generated  from  data  stored  in  the 
PWILST  during  the  Data  Link  Message  Pre-processing  Task  (dis¬ 
cussed  in  Section  8).  At  the  conclusion  of  data  link  message 
pre-processing,  the  PWILST  has  accumulated  entries  containing 
all  data  required  for  messages.  Each  entry  has  been  categorized 
by  conflict  (encounter)  type  into  resolution,  threat  or  proximity 
classes,  but  the  categories  are  not  sorted  by  type,  the  entries 
within  each  category  are  not  sorted,  and  more  data  may  exist 
than  can  be  accommodated  by  the  DABS  sensor. 

The  sequence  of  messages  generated  is  determined  by  the  order  of 
entries  in  the  PWILST,  thus,  further  processing  of  the  PWILST 
must  occur  before  messages  can  be  generated. 

14.1.1  Sorting,  Ranking,  Establishing  the  Most  Critical  Entry 
in  the  PWILST 


Each  entry  in  the  PWILST  has  an  encounter  type  recorded  in  the 
header  segment.  As  discussed  in  Section  8,  these  types  may  be 
R,  TR,  IN,  T,  or  P.  Any  of  these  types  may  have  the  End  Flag 
(ENDFLG)  set  if  the  entry  was  not  updated  on  this  scan.  Type  R 
entries  with  ENDFLG  set  are  moved  to  the  top  of  the  set  of 
resolution  entries.  Other  types  with  ENDFLG  set  are  moved  to 
the  end  of  the  PWILST  and  the  type  is  changed  to  E  for  end 
encounter.  All  types  with  ENDFLG  not  set  are  sorted  by  en¬ 
counter  type. 

Within  each  threat  or  proximity  encounter  category,  where  two  or 
more  threat  or  proximity  encounters  exist,  the  message  sequence 
is  determined  from  the  ranking  of  each  aircraft.  This  ranking 
is  based  conceptually  on  the  severity  of  the  encounter  and  is  a 
number  which  provides  a  mechanism  for  sorting  the  encounters  and 
choosing  the  most  critical  encounter. 


The  ranking  for  several  threat  encounters  is  based  first  on  the 
threat  category,  second  on  the  value  of  horizontal  tau  within 
the  category  and  third  on  the  value  of  range  within  one  hori¬ 
zontal  tau  category.  The  highest  ranking  encounter  is  defined 
as  the  one  with  the  lowest  tau  (or  range  if  used). 

Threat  encounters  are  divided  into  two  categories:  threats  that 
also  require  resolution  (based  on  the  severity  of  the  encounter) 
and  threats  that  do  not  require  resolution.  Within  each  of 
these  two  categories,  tau  is  computed  using  the  rules  below. 

1.  When  the  MTTFLG  is  set  in  the  Detect  Task,  a  "pseudo- 
tau"  is  computed  from  the  horizontal  range  divided  by  the 
sum  of  the  two  aircraft  velocities. 

2.  Where  threats  are  diverging,  a  large  constant  is 
assigned  to  tau  (LRGTAU). 

3.  When  neither  of  the  two  cases  above  is  true,  tau  is 
the  same  value  computed  in  the  Detect  Task. 

If  two  or  more  threat  encounters  within  one  category  have  the 
same  horizontal  tau,  these  encounters  are  ranked  on  the  basis  of 
range  between  the  two  aircraft  where  vertical  separation  is 
weighted  by  a  factor  of  five  relative  to  lateral  separation. 

The  ranking  for  several  proximity  encounters  is  based  on  the 
range  between  the  two  aircraft  where  vertical  separation  is 
weighted  by  a  factor  of  five  relative  to  lateral  separation. 

The  highest  ranking  encounter  is  defined  as  the  one  with  the 
lowest  numerical  range. 

When  ranking  is  completed,  three  sorted  categories  of  threat  and 
proximity  encounters  may  exist: 

1.  threats  that  require  resolution, 

2.  threats  that  do  not  require  resolution,  and 

3.  proximities. 

For  the  purpose  of  selecting  the  most  critical  encounter,  these 
three  categories  are  consolidated  into  threats  and  proximities. 
Selection  of  the  most  critical  encounter  is  based  on  two  rules. 

1.  An  encounter  displayed  to  the  pilot  as  most  critical 
must  continue  to  be  displayed  for  two  scans  unless  a  higher 
encounter  category  exists. 
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2.  Encounters  in  the  threat  category  are  more  critical  than 
encounters  in  the  proximity  category. 


Wnen  encounters  exist  in  both  categories,  the  most  critical 
encounter  is  the  highest  ranking  threat  encounter  unless  a  lower 
ranking  threat  encounter  exists  that  was  previously  selected  as 
most  critical  one  time  but  not  more  than  two  times.  If  this  low 
ranking  previously  most  critical  threat  exists,  it  is  selected 
as  most  critical.  Low  ranking  threat  encounters  selected  as 
most  critical  using  the  two  times  rule  are  moved  to  the  top  of 
the  rank  order.  If  a  proximity  encounter  exists  that  was  pre¬ 
viously  selected  most  critical,  it  is  replaced  as  most  critical 
by  the  new  threat  encounter. 

When  encounters  exist  in  only  one  category,  the  most  critical 
encounter  is  the  highest  ranking  encounter  in  the  category 
unless  a  lower  ranking  encounter  in  that  category  exists  that 
was  previously  selected  as  most  critical  one  time  but  not  more 
than  two  times.  If  this  low  ranking  previously  most  critical 
encounter  exists,  it  is  selected  as  most  critical.  Low  ranking 
encounters  selected  using  the  two  times  rule  are  moved  to  the 
top  of  the  rank  order. 

If  a  message  based  on  an  encounter  that  is  marked  most  critical 
is  not  successfully  delivered,  the  encounter  does  not  need  to  be 
marked  most  critical  the  next  time  unless  it  appears  at  the  top 
of  the  rank  order  based  on  tau  or  range  alone. 

After  the  PWILST  is  sorted,  ranked  and  arranged  by  most  critical, 
the  list  will  be  in  the  order  shown  in  Figure  14-1. 

14.1.2  Assigning  Track  Numbers,  Deleting  Entries  Without 
Numbers  in  tne  PWILST 


After  the  PWILST  is  arranged  in  order,  each  encounter  is  assigned 
a  track  number  (PWINO)  from  zero  to  seven.  If  more  than  eight 
encounters  exist,  any  old  encounters  that  rank  below  eight  in  the 
list  may  be  deleted  and  the  numbers  reassigned  to  new  entries,  or 
any  new  entries  without  numbers  ranking  below  eight  in  the  list 
may  be  deleted.  In  the  special  case  when  two  list  entries  exist 
for  a  paired  TR/R  (threat  and  resolution)  case,  the  track  number 
is  the  same  for  both  entries  and  must  be  assigned  to  both 
entries  when  they  are  new. 

14.1.3  Establishing  Message  Contents  From  Entries  in  the  PWILST 

Although  the  sequence  of  messages  is  determined  from  the  order 
of  the  PWILST,  the  data  in  the  message  delivered  to  the  aircraft 
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FIGURE  14-1 

DESCRIPTION  OF  ORDERED  PWILST  AFTER  THE  SORT  AND 
SET  CRITICALITY  ROUTINE  ARE  COMPLETED 


depends  on  the  exact  encounter  status  (types  and  number  of 
PWILST  segments)  at  the  time  the  message  is  delivered. 

If  two  Proximity  Segments  exist  in  the  PWILST,  the  position  data 
from  the  first  segment  is  combined  with  the  position  data  from 
the  second  segment  to  form  a  single  message  for  the  aircraft. 

If  an  Own  Message  is  required  the  own  data  may  be  combined  with 
start  threat  data  (if  start  threat  is  required)  or  with  position 
or  supplementary  data  (where  a  proximity  is  required)  to  form  a 
single  message.  Table  14-1  shows  an  example  of  advisory  message 
contents  for  four  encounters. 

The  message  types  shown  in  the  example  are  a  subset  of  the  types 
of  messages  that  may  occur.  Table  14-2  provides  a  list  of  all 
message  types  currently  defined.  As  shown  in  this  table,  14 
different  message  types  currently  exist.  The  conflict  messages 
include  three  resolution  messages  (ADS  #59,  61,  63),  two  threat 
messages  (ADS  #29,  30),  and  five  proximity  messages  (ADS  #25, 

26,  27,  28,  31).  The  remaining  message  types  are  non-conflict 
messages  which  are  discussed  in  Section  14.2  below. 

14.2  Non-conflict  Messages 

The  two  types  of  non-conflict  messages  that  may  be  generated  are 
the  Own  Message  (ADS  #24)  and  alert  messages  for  terrain, 
obstacle  or  restricted  airspace  (ADS  #16,  17,  18).  The  own 
message  data  verifies  proper  operation  of  the  DABS  sensor  and 
transponder  and  informs  the  pilot  that  he  is  within  ATARS 
coverage.  The  data  may  also  be  used  to  display  ATARS  ground 
track  heading,  velocity  and  turn  rate.  The  contents  of  the  Own 
Message  is  shown  in  Tables  14-3  through  14-5.  The  alert  messages 
for  obstacles,  terrain,  or  restricted  airspace  are  information 
messages  for  the  pilot. 

14.3  Message  Construction  Summary 

The  Data  Link  Message  Construction  Task  is  subdividied  into  three 
major  parts:  Compute  Criticality  Routine,  Message  Construction 
Routine,  and  the  Final  Message  Processing  Routine.  Compute 
criticality  includes  the  following  steps: 

1.  sort  in  order  by  type  and  rank, 

2.  mark  the  most  critical  threat  or  proximate  encounter, 

3.  assign  track  numbers  for  new  entries,  and 
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TABLE  14-1 


MESSAGES  REQUIRED  FOR  AN  ENCOUNTER 
(No  Threats,  6  Proximities,  Own  Required) 


MESSAGE  TYPE 

ADVISORY 

MESSAGE 

DATA  IN  FI ELD 1 

DATA  IN  FIELD2 

DUAL  PROXIMITY 

POSITION 

POSITION 

DUAL  PROXIMITY 

POSITION 

POSITION 

DUAL  PROXIMITY 

POSITION 

POSITION 

OWN+SUPPLEMENTARY 

OWN 

SUPPLEMENTARY 

(2  Threats,  3  Proximities,  Own  Not 

Required) 

MESSAGE  TYPE 

ADVISORY  MESSAGE 

DATA  IN  FI ELD 1 

DATA  IN  FIELD2 

THREAT 

BASIC  THREAT 

POSITION 

THREAT 

BASIC  THREAT 

POSITION 

DUAL  PROXIMITY 

POSITION 

POSITION 

SINGLE  PROXIMITY 

POSITION 

SUPPLEMENTARY 

(No  Threats,  6 

Proximities,  Start  Prox  Requ 

ired,  Own  Required) 

MESSAGE  TYPE 

ADVISORY 

MESSAGE 

DATA  IN  FIELD 1 

DATA  IN  FIELD2 

START  PROXIMITY 

START 

POSITION 

DUAL  PROXIMITY 

POSITION 

POSITION 

DUAL  PROXIMITY 

POSITION 

POSITION 

OWN+PROXIMITY 

POSITION 

OWN 

(2  Threats,  Start 

Threat  Required,  3 

Proximities,  Own  Required 

MESSAGE  TYPE 

ADVISORY  MESSAGE 

DATA  IN  FI ELD 1 

DATA  IN  FIELD2 

THREAT 

BASIC  THREAT 

POSITION 

START  THREAT 

START  THREAT 

OWN 

DUAL  PROXIMITY 

POSITION 

POSITION 

SINGLE  PROXIMITY 

POSITION 

SUPPLEMENTARY 
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TABLE  14-2 


ADVISORY  DEFINITIONS 


MESSAGE  TYPE* 

PRIORITY 

ADS 

(8  BITS) 

FIELD  1 

DATA  (24  BITS) 

FIELD  2 

DATA  (24  BITS) 

Own 

0 

24 

Own 

Blank  (Set  =  0) 

Own  +  Proximity 

0 

25 

Position 

Own 

Start  Proximity 

0 

26 

Start/End 

Position 

Dual  Proximity 

0 

27 

Position 

Position 

Single  Proximity 

0 

28 

Position 

Supplementary 

Proximate 

Start  Threat 

0 

29 

Start  Threat 

Own 

Threat 

1 

30 

Basic  Threat 

Position 

Own  +  Supplementary 
Proximity 

0 

31 

Own 

Supplementary 

Proximate 

Resolution 

1 

59 

DABS  Resolution 

Advisory  Format 

Resolution 

1 

61 

ATCRBS  Resolution  Advisory  Format 

Resolution 

1 

63 

ATCRBS  Track  Block  Format 

Terrain 

1 

16 

DABS  ID 

Blank  (Set  =  0) 

Obstacle 

1 

17 

DABS  ID 

Blank  (Set  =  0) 

Airspace 

*  See  Reference  9. 

1 

18 

DABS  ID 

Alert  Type 
Indicator 
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TABLE  14-3 


OWN  DATA 


FIELD 

BITS 

INTERPRETATION 

Own  Ground  Track  Heading 
(OGTH) 

7 

0°  to  360°:  (OGTH)  *  2.8125° 
referenced  to  magnetic  north  of 

DABS  site 

Own  Ground  Track  Speed 
( OGTS ) 

7 

0  to  1270  kts:  (OGTS)  *  10  kts 

Own  Ground  Track  Turn 

Rate  (OGTTR) 

4 

0  to  +  7  degrees/second  (two's 
complement  with  left  (l)  and 
right  (0)) 

Own  ATARS  Capability 

2 

4  levels  possible  (only  01  used 
at  present) 

Seam  Bit 

1 

Multi  (1)  or  single  (0)  ATARS 
sites  can  uplink  threat, 
proximate  or  own  data 

Time 

3 

Antenna  scan  period  in  seconds 
minus  four,  rounded  to  nearest 
integer.  If  period  is  greater  than 
11  seconds  report  as  7  (i.e.,  Ill) 

TOTAL 


24 


TABLE  14-4 


SOURCE  OF  OWN  DATA 


FIELD 

Own  Ground  Track  Heading 
(OGTH) 

Own  Ground  Track  Speed 
(OGTS) 

Own  Ground  Track  Turn  Rate 
(OGTTR) 

Own  ATARS  Capability 

Seam  Bit 

Time 


SOURCE 

Table  14-5,  Equation  I 
Table  14-5,  Equation  II 

State  vector 

State  vector 

GEOG  field  in  state  vector 
and  Table  14-5 

Table  14-5,  Equation  VI 


TABLE  14-5 


OWN  DATA  FIELDS 


I  Own  Ground  Track  Heading  (OGTH) 

=  INT  (ARC  COT  (YDl/XDl)/2. 81250) 

Note:  Correct  for  proper  quadrant 

II  Own  Ground  Track  Speed  (OGTS) 

=  INT  ( SQRT  (VSQD/10  kts) 

III  Own  Ground  Track  Turn  Rate  (OGTTR) 

IV  Own  ATARS  Capability  (Code  01  is  equipped) 

V  Seam  Bit  (Set  to  zero  if  GEOG  field  in  the  state  vector 

own-site) 

VI  SCANTM  -  4.7  sec 
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4.  if  more  than  eight  entries  exist,  delete  low  ranking 
entries  until  only  eight  remain. 


Message  construction  includes  the  following  steps: 

1.  determine  if  an  Own  Message  is  required  (according  to 
Table  14-6),  compute  own  data  if  needed,  set  0WNFL1, 

2.  set  up  UPLST/ACLST  for  a  new  message  set, 

3.  determine  the  types  of  threat  advisories  required 
according  to  Table  14-7, 

4.  determine  the  types  of  proximity  advisories  required 
according  to  Table  14-8, 

5.  determine  if  end  encounter  advisories  are  required  (if 
any  exist  in  the  PWILST),  and 

6.  determine  if  an  Own  Message  is  required  (based  on  the 
value  of  0WNFL1 ) . 

As  each  message  is  constructed,  a  relative  pointer  value  is 
assigned  to  each  message  based  on  the  current  value  of  UPMES  and 
the  ADS  message  number  is  assigned  as  specified  in  Table  14-2. 

Final  message  processing  includes  the  following  steps: 

1.  determine  if  obstacle,  terrain  or  airspace  alert 
messages  are  required  (  based  on  the  value  of  flags), 

2.  if  resolution  messages  exist  in  UPLST,  insert  the 
terrain,  obstacle  or  airspace  warning  messages  below  the 
resolution  messages, 

3.  generate  terrain,  obstacle  or  airspace  Controller  Alert 
Messages  indicating  a  terrain,  obstacle,  or  airspace  alert, 
and 


4.  prepare  all  messages  for  uplink  by  assigning  all  header 
fields  as  specified  in  Figure  14-2. 

Figures  14-3  through  14-12  provide  additional  detail  on  the 
logic  of  the  Data  Link  Message  Construction  Task. 
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TABLE  14-6 


OWN  REQUIRED 


An  Own  Message  is  required  whenever  any  of  the  following  conditions 
is  true. 


1.  The  seam  bit  setting  has  changed  since  the  last  Own  Message 
was  delivered  successfully. 

2.  The  absolute  value  of  (Own  Ground  Track  Heading  (OGTH)  minus 
aircraft’s  calculation  of  OGTH)  is  greater  than  OGHDIF,  where 
aircraft  calculation  of  OGTH  is  based  on  last  Own  Message  OGTH 
plus  (own  ground  track  turn  rate  times  the  elapsed  time  since 
the  last  Own  Message  was  successfully  delivered). 

3.  The  last  Own  Message  sent  was  not  successfully  delivered. 

4.  A  new  aircraft  is  ready  for  ATARS  processing  (0WNFL1  set). 
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TABLE  14-7 


START  THREAT  AND  THREAT  ADVISOR?  REQUIRED 


loth  a  start  threat  and  a  threat  advisory  are  required  whenever  any 
>f  the  following  conditions  is  true. 

1.  A  new  encounter  (i.e.  not  transitioning  from  proximity 
status)  STFLG  set. 

2.  A  threat  encounter  is  transitioning  from  a  proximity  and  an 
Own  Message  is  required. 

3.  A  threat  encounter  is  transitioning  from  a  proximity  and  the 
absolute  value  of  (velocity  of  the  threatening  aircraft 
currently  being  used  by  ATARS  on  the  ground  minus  the  velocity 
of  the  threatening  aircraft  last  transmitted  to  "own"  aircraft) 
is: 

a.  greater  than  THVPER  times  the  velocity  being  used  by 
ATARS  and 

b.  greater  than  THVDIF  kts. 

4.  The  last  start  threat  advisory  sent  was  net  successfully 
delivered. 

If  none  of  the  conditions  requiring  both  a  start  threat  and  a  threat 
advisory  are  true,  a  threat  advisory  is  delivered. 


14-13 


i 


TABLE  14-8 


PROXIMITY  MESSAGE  TYPES  REQUIRED* 


ADS 

25 


26 


27 

28 


31 


MESSAGE  NAME 


Own  +  Proximity 


Start  Proximity 


CONDITION 


An  Own  Message  is  required  and  one 
Proximity  Segment  remains  after  all 
dual  proximities  are  paired. 

The  last  Start  Proximity  Message 
was  not  successfully  delivered  or 
the  proximity  encounter  is  new 
(STFLG  set). 


Dual  Proximity 


Two  Proximity  Segments  exist. 


Single  Proximity  An  Own  Message  is  not  required  and 

one  Proximity  Segment  remains  after 
all  dual  proximities  are  paired. 


Own  +  Supplementary  An  Own  Message  is  required  and  no 
Proximity  Proximity  Segments  remain  after  all 

dual  proximities  are  paired. 


*  Tnese  conditions  must  be  checked  in  the  order  ADS  #26,  27,  25,  28 
and  31  as  shown  in  Figure  14-10  (Enter  Proximity  Advisories 
Routine) 
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C  DBF  G 
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HEADER  FIELDS 


MESSAGE  FIELD 


FIELD  BITS 
A  S 

B  24 

C  4 

D  1 

E  3 


F  4 

G  8 

H  48 


FIELD  DESCRIPTION* 

Message  Type  Code  (mono-link  *  1010  GOOD 
DABS  Address  (24  bit  ID  code  for  DABS  aircraft) 
Message  No 

Priority  (see  Table  14-2) 

Expiration  Time  (always  *  1  scan) 

ATARS  Site  Identification  Code  of  Sending  Site 
ADS  Code  (see  Table  14-2) 

Message  (see  Table  14-2) 


*  See  Reference  8. 
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SET  CRITICALITY  ROUTINE  (Page  1  ol  2) 
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ASSIGN  NEW  TRACK  NUMBERS  ROUTINE  (Pag*  4  o<  4) 
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FIGURE  14-9 

ENTER  RESOLUTION  AND  THREAT  ADVISORIES  ROUTINE 
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ENTER  PROXIMITY  ADVISORIES  ROUTINE  (Pag*  1  of  2) 
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FIGURE  14-10 

ENTER  PROXIMITY  ADVISORIES  ROUTINE  (Pa«o  2  of  2) 
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FIGURE  14-12 

FINAL  MESSAGE  PROCESSING  ROUTINE 


15.  FAILURE  MODE  OPERATION 


Protection  against  numerous  types  of  failures  is  incorporated  in 
the  ATARS  system  design.  Specific  features  are  provided  to  cope 
with  the  following  ATARS-specif ic  failures; 

1.  Failure  to  receive  a  target  report  from  the  local 
sensor. 

2.  False  altitude  or  track  association  in  target  report 
from  local  sensor. 

3.  Failure  to  deliver  traffic  or  resolution  advisory  by 
local  sensor. 

4.  Incomplete  CIR  downlink  report  from  local  sensor. 

5.  ATARS  selects  a  resolution  advisory  which  is 
incompatible  with  an  aircraft's  exisiting  resolution 
advisories. 

6.  Failure  of  a  ground  communication  channel  between 
sensors. 

7.  Where  a  ground  communication  channel  is  not  provided, 
or  has  failed,  ATARS  selects  resolution  advisories,  not 
knowing  the  pair  of  aircraft  is  already  being  resolved 
by  another  ATARS  site. 

8.  Failure  of  the  DABS  sensor  at  a  single  site. 

9.  Failure  of  the  ATARS  function  at  a  single  site. 

10.  Catastrophic  failure  of  an  ATC  facility. 

Logic  for  items  8  and  9  is  contained  in  this  section.  The 
features  which  accommodate  the  other  items  are  found  in  other 
sections  of  this  document.  All  the  capabilities  are  discussed 
here  to  summarize  the  robust  nature  of  the  overall  design. 

15.1  Missing  Target  Report 

If  the  local  sensor  misses  a  target  report  on  an  aircraft,  it 
requests  a  report  from  an  adjacent  sensor.  ATARS  performs 
coordinate  and  time  conversion  for  the  remote  report  and  uses  it 
to  update  the  track  for  the  aircraft.  If  the  aircraft  is 
equipped  with  a  CIR,  ATARS  requests  a  CIR  report  from  the  remote 
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sensor.  Even  if  that  sensor  was  not  previously  reading  the 
aircraft's  CIR,  the  remote  sensor  may  do  so  by  "borrowing"  the 
local  ATARS  ID.  This  prevents  confusion  among  ATARS  sites  as  to 
the  aircraft's  location  in  an  ATARS  seam. 

When  a  sensor  detects  an  aircraft  passing  into  its  antenna's 
zenith  cone  ("cone  of  silence"),  it  requests  an  adjacent  sensor 
to  provide  target  reports  continuously  until  told  to  stop.  In  a 
like  manner,  ATARS  requests  CIR  reports  from  the  adjacent 
sensor,  for  an  equipped  aircraft,  to  be  provided  until  told  to 
stop. 

If  no  target  report  is  obtained  from  any  sensor  (e.g.,  no 
adjacent  sensor  covered  the  aircraft's  location  or  no  ground 
communication  channel  is  operating),  ATARS  coasts  the  track 
using  its  last  estimates  of  position  and  velocity.  Full 
conflict  detection  continues.  If  no  report  is  received  by  a 
predetermined  time,  ATARS  drops  the  track. 

If  a  position  report  is  received  with  altitude  missing,  the 
altitude  estimate  is  coasted.  If  a  target  report  is  received 
but  CIR  data  is  missing,  ATARS  assumes  the  last  known  CIR 
contents  are  unchanged,  rather  than  assuming  an  empty  CIR. 

15.2  Target  Report  Contains  False  Altitude  or  Track  Association 

ATARS  maintains  tracks  on  aircraft  in  its  service  area  which  are 
independent  of  DABS  surveillance  tracks.  Since  the  requirements 
of  a  collision  avoidance  system  differ  from  a  surveillance 
system,  ATARS  uses  its  own  criteria  for  establishing  or  dropping 
tracks. 

ATARS  performs  a  reasonability  check  on  each  altitude  report. 

If  unreasonable,  the  altitude  report  is  ignored.  If  a  falsely 
decoded  altitude  is  sufficiently  reasonable  to  be  accepted,  it 
is  smoothed  by  the  tracker  and  thus  is  unlikely  to  seriously 
affect  ATARS  service. 

The  requirements  for  starting  a  new  track,  especially  for 
non-discrete  beacon  codes,  ensures  that  phantom  aircraft  tracks 
are  very  unlikely. 

15.3  Sensor  Fails  to  Deliver  Traffic  or  Resolution  Advisory 


Although  the  DABS  data  link  is  very  reliable,  the  sensor  may 
occasionally  fail  to  deliver  traffic  or  resolution  advisories. 
When  a  target  report  was  received,  but  part  or  all  of  the  ATARS 


messages  were  not  delivered  during  the  beam  dwell,  ATARS  has 
good  reason  to  believe  that  the  aircraft  is  still  visible  to  the 
sensor.  ATARS  simply  computes  updated  advisories  for  the  next 
scan.  In  the  meantime,  the  avionics  retains  the  existing  advi¬ 
sories  until  they  are  updated,  or  until  a  time  out  several  scans 
in  length  has  expired.  The  avionics  ignores  any  incomplete 
resolution  uplinks  that  may  have  been  delivered.  When  an  ATARS 
uplink  message  was  attempted  and  not  even  a  target  report  was 
successfully  achieved  by  the  local  sensor,  ATARS  immediately 
attempts  to  deliver  its  messages  through  one  (and  only  one) 
adjacent  connected  sensor.  The  adjacent  sensor  borrows  the 
local  ATARS  ID,  regardless  of  whether  or  not  its  own  ATARS  is 
providing  service  to  the  aircraft.  The  DABS  multi-Link  protocol 
may  not  be  used  for  ATARS  uplink  messages. 

15.4  Incomplete  CIR  Downlink  Report 

An  incomplete  CIR  downlink  report  is  ignored.  If  ground  communi¬ 
cation  lines  to  adjacent  sites  are  operating,  the  multi-site 
ground  protocol  provides  complete  current  information  regarding 
seam  conflicts.  A  complete  CIR  downlink  is  very  likely  to  be 
received  on  the  next  scan. 

15.5  ATARS  Selects  Incompatible  Resolution  Advisory 

ATARS  resolution  logic  always  selects  new  resolution  advisories 
compatible  with  an  aircraft's  existing  resolution  advisories. 
However,  if  an  existing  advisory  is  not  known  to  the  ground,  an 
incompatible  (i.e.,  contradictory)  sense  advisory  could  be  up- 
linked.  This  could  happen  if  a  BCAS  outside  ATARS  coverage 
(called  a  "pop-up"  threat)  initiated  resolution  with  the  subject 
aircraft  since  the  last  CIR  downlink;  or  if  another  ATARS  site, 
unconnected  by  a  ground  communications  line,  resolved  another 
conflict  since  the  last  CIR  downlink. 

Any  incompatible  advisory  is  ignored  by  the  ATARS  avionics.  The 
CIR  performs  a  compatibility  check  for  every  uplinked  advisory. 

If  multiple  advisories  are  being  uplinked,  all  compatible  advi¬ 
sories  will  be  accepted  even  if  others  are  incompatible  and 
ignored.  ATARS  reads  down  a  copy  of  the  CIR  contents  as  they 
existed  at  the  time  the  CIR  was  first  accessed  (typically  near 
the  beginning  of  the  current  beam  dwell).  ATARS  duplicates  the 
avionics'  compatibility  logic  to  immediately  determine  whether 
each  of  its  uplink  advisories  will  be  accepted.  For  any  which 
are  found  incompatible,  new  advisories  are  recomputed  for  deli¬ 
very  the  next  scan,  taking  account  of  the  updated  copy  of  the 
CIR  contents. 


15.6  Failure  of  Ground  Communications  Channel 

A  ground  communications  channel  Detween  sensors  is  not  a 
critical  element  for  ATARS  operation.  Where  a  network  of  more 
than  two  DABS  sensors  exists,  the  loss  of  a  ground  channel 
prompts  DABS  network  management  to  establish  alternate  message 
paths.  Whenever  this  succeeds,  the  ground  channel  failure  is 
transparent  to  ATARS. 


When  ATARS  becomes  unconnected  to  a  neighbor,  some  degradatic' 
of  service  will  occur,  since  remote  reports,  cone  of  silence 
coverage,  and  remote  uplink  become  unavailable.  However,  the 
majority  of  service,  including  multi-site  coordination  of 
conflict  resolution,  continues  unaffected.  The  CIR  is  used  as 
the  coordinating  device  for  all  resolution,  and  responsibility 
is  unchanged. 

15.7  Resolution  Duplicating  That  Provided  by  Another  Site 

Whenever  a  ground  communication  channel  is  available,  positive 
coordination  between  sites  assumes  that  only  one  site  at  a  time 
issues  resolution  advisories  to  a  particular  pair  of  aircraft. 
However,  when  no  channel  is  provided,  or  when  the  channel  has 
failed,  such  duplicate  service  may  be  attempted  in  certain 
situations.  This  would  happen  when  a  DABS-ATCRBS  pair  in  an 
ATARS  seam  comes  into  conflict  since  the  last  CIR  downlink;  or 
when  a  DABS-DABS  pair  flies  into  an  ATARS  seam  and  site  respons¬ 
ibility  changes  just  before  the  conflict  begins,  and  one  site 
has  been  unable  to  read  down  the  CIR  site  ID  bits  for  at  least 
one  scan  since  they  changed.  The  latter  situation  is  a  compound 
event  of  low  probability. 

To  prevent  duplicate  resolution  of  a  pair,  since  the  two  sites 
might  select  incompatible  resolution,  every  CIR  "row"  (stored 
resolution  advisory)  is  marked  with  the  ID  of  the  ATARS  site 
that  created  it.  No  other  site  may  change  the  row.  If  the 
aircraft  leaves  the  original  site's  service  area,  the  site  sends 
a  message  to  release  its  control  of  the  row.  If  the  ground-air 
link  is  lost,  the  row  is  deleted  by  the  avionics  time  out  feature 
and  a  different  site  may  then  resolve  the  pair. 

15.8  Failure  of  the  DABS  Sensor 

The  DABS  sensor  is  complex  and  may  fail  in  a  variety  of  ways, 
many  of  which  are  beyond  the  scope  of  this  document.  Any  failure 
which  causes  the  local  ATARS  function  to  fail  is  treated  in 
Sect  ion  15.9. 


If  only  the  surveillance  function  or  RF  channel  fails,  so  that 
ATARS  continues  to  operate,  data  from  remote  sensors  may  be  used 
as  described  in  Sections  15.1,  15.3,  and  15.4.  In  this  case, 
ATARS  attempts  to  provide  service  in  its  usual  area,  but  is 
limited  to  servicing  those  aircraft  seen  by  adjacent  connected 
sensors. 

15.9  Failure  of  ATARS  Function 


Any  network  of  neighboring  DABS  sensors  may  take  advantage  of 
overlapping  DABS  coverage  for  the  ourpose  of  allocating 
replacement  coverage  for  a  failed  ATARS  site.  This  section 
discusses  the  means  for  recognition  of  a  failed  ATARS  and  the 
action  to  be  taken. 

15.9.1  Status  Message  Processing  and  Backup  Mode 

Each  DABS  sensor  contains  a  performance  monitoring  function. 

Once  per  scan,  the  sensor  sends  sensor  status  and  ATARS  Status 
Messages  to  all  adjacent  sensors.  ATARS  is  only  interested  in 
the  status  ("operational"  or  "failed")  of  the  ATARS  function  of 
each  of  its  neighbors.  ATARS  periodically  performs  the  Function 
Status  Message  Processing  Routine  shown  in  Figure  15-1.  This 
routine  examines  all  remote  ATARS  status  message  which  have  been 
queued  since  the  last  execution  of  the  routine.  The  routine 
maintains  a  Function  Failure  Flag  ( FFF )  Indicating  the  status  of 
each  remote  ATARS.  However,  the  logic  only  accommodates  a 
single  remote  ATARS  failure. 

Upon  recognizing  the  first  such  failure,  the  Backup  Mode 
Initiation  Routine  (Figure  15-2)  is  called.  This  routine 
replaces  the  ATARS  service  zone  mask  with  the  backup  service 
zone  mask  corresponding  to  the  failed  ATARS.  If  own  ATARS  is 
due  to  become  the  "master"  site  for  this  failure  (see  Section 
15.9.2),  a  substitute  priority  table  is  invoked.  This  replaces 
the  normal  table  used  to  determine  whether  own  ATARS  is  the  site 
responsible  for  a  pair  of  rircraft  (see  Section  7.2).  When  the 
substitute  table  is  used,  both  the  failed  site's  ID  and  own- 
site's  usual  ID  are  considered  to  be  "own”  ID.  This  is  also 
true  in  all  other  places  in  the  algorithms  which  test  for  "GEOG 
contains  own  ID"  or  "ATSID  equal  to  own  ID."  ATARS  does  not 
assume  a  remote  ATARS  failure  when  a  communication  line  fails. 

When  an  "operational  status"  message  is  received  from  a 
previously  failed  ATARS,  the  Backup  Mode  Termination  Routine  is 
executed.  This  routine  merely  reinstates  the  normal  service 
area,  resets  the  master  flag,  and  reinstates  the  normal  priority 
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Cable.  It  is  not  necessary  to  send  conflict  tables  to  the 
recovered  site,  since  that  site  should  be  able  to  immediately 
read  down  aircraft  CIR's,  and  may  request  conflict  tables  from 
its  neighbors  over  ground  lines.  When  the  (smaller)  normal 
service  mask  is  reinstated,  aircraft  outside  this  mask  will  be 
dropped  by  the  ATARS  tracker  in  the  normal  way,  just  as  if  they 
had  flown  out  of  the  service  zone. 

15.9.2  Backup  ATARS  Service  Areas 

In  a  region  having  several  DABS  sensors  located  within  reason¬ 
able  proximity,  some  flexibility  may  exist  in  drawing  the  ATARS 
map  boundaries.  The  choice  of  boundaries  will  take  into  account 
geographical  coverage,  terrain  features  and  the  expected  traffic 
load  for  the  sensors.  Upon  the  failure  of  one  ATARS  site,  other 
sensors  with  overlapping  coverage  may  be  capable  of  replacing 
the  failed  ATARS.  If  the  failed  site  was  serving  a  large  load 
of  traffic,  no  single  neighbor  may  have  sufficient  capacity  to 
absorb  it  all.  Therefore,  a  better  strategy,  where  geographic 
coverage  and  terrain  features  permit,  is  to  divide  the  failed 
site's  service  area  among  several  neighbors. 

An  example  of  this  operation  is  depicted  in  Figure  15-3.  Here, 
when  the  site  with  ID  0010  fails,  its  two  neighbors  each  expand 
their  coverage  and  share  the  failed  site's  area.  The  two 
surviving  sites'  maps  should  provide  an  overlap  (seam)  of  the 
usual  width.  In  this  case,  no  "master"  site  or  "center"  zone 
(see  below)  is  required.  Both  surviving  sites  operate  normally, 
and  treat  newly  acquired  aircraft  in  their  expanded  service  areas 
in  the  same  manner  as  any  aircraft  which  has  just  entered  the 
normal  service  area.  Any  of  these  aircraft  having  CIR  rows 
created  by  the  failed  site  will  soon  have  them  released  by  the 
avionics  time  out.  This  is  likely  to  happen  even  before  the 
surviving  site  has  established  its  new  ATARS  track  on  the 
aircraft.  Thus  no  special  measures  are  required. 

The  surviving  sites  may  not  be  connected  with  ground  communi¬ 
cations  lines.  In  this  case,  all  coordination  is  performed 
through  the  transponders  using  the  CIR  features,  as  explained  in 
Sections  12.2  and  15.6. 

In  certain  configurations  of  ATARS  sites,  the  simple  procedure 
described  above  cannot  be  used.  Since  only  four  distinct  ATARS 
ID's  are  assigned,  the  failure  of  an  ATARS  may  cause  two  sites 
assigned  the  same  ID  to  become  adjacent,  if  the  most  desirable 
backup  service  map  were  implemented.  Since  the  multi-site 
protocol  does  not  permit  this  condition,  several  alternatives 
are  available.  Using  another  neighbor  to  cover  the  failed  area 
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may  be  feasible,  but  geographic  considerations  may  prohibit  this 
choice.  Leaving  a  coverage  gap  without  ATARS  is  very  undesir¬ 
able.  The  solution  implemented  in  this  design  is  to  designate 
one  of  the  surviving  sites  as  the  "master"  site.  This  should  be 
the  site  with  the  best  geographical  coverage  of  the  part  of  the 
failed  area  that  separates  the  two  sites  having  the  same  ATARS 
ID.  The  "master"  site  then  continues  to  serve  its  own  ATARS 
area  using  its  own  ID,  and  also  serves  a  small  "center"  zone 
within  the  failed  site's  area,  borrowing  the  failed  site's  ATARS 
ID  to  send  to  aircraft  in  this  area.  This  is  illustrated  in 
Figure  15-4.  The  "center"  zone  should  be  made  small,  so  all 
sites  may  use  their  own  ID  in  as  large  an  area  as  possible,  but 
sites  with  like  ATARS  ID's  must  be  separated  by  more  than  the 
usual  seam  width. 

The  "master"  site  performs  an  extra  masking  (in  this  backup 
mode)  to  decide  which  of  the  aircraft  in  its  expanded  coverage 
are  in  the  "center"  zone  and  thus  are  to  receive  the  failed 
site's  ID.  The  "master"  site  still  uses  its  own  sensor  to  serve 
both  of  its  areas,  sending  different  ATARS  ID's  to  aircraft 
according  to  their  location.  The  "center"  zone  is  mapped  to 
have  the  usual  overlap  (seam)  with  all  of  its  neighboring  sites 
except  the  "master"  site.  No  overlap  is  provided  between 
master's  own  area  and  its  "center"  zone.  The  master  ATARS  keeps 
aircraft  in  both  of  its  areas  in  the  same  data  base,  and  is  able 
to  treat  the  boundary  between  its  two  areas  as  "soft".  This 
means  that  if  an  aircraft  receiving  resolution  crosses  this 
boundary,  the  "master"  site  may  continue  to  send  resolution 
advisories  without  changing  the  site  ID  for  that  aircraft. 

15.10  Failure  of  the  ATC  Facility 

ATARS  normally  serves  controlled  aircraft  only  as  a  backup  to 
ATC.  When  aircraft  come  into  conflict  in  sufficiently  hazardous 
situations,  ATARS  issues  traffic  and  resolution  advisories. 

This  action  is  performed  routinely,  and  in  the  event  of  a 
catastrophic  ATC  failure,  ATARS  continues  to  provide  full 
service. 

It  is  possible  to  implement  a  backup  area  type  map  which  would 
be  invoked  upon  receipt  of  an  ATC  Failure  Message.  No  specific 
logic  for  this  feature  is  provided. 
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TABLE  A-l 


SYSTEM  PARAMETERS  (ALPHABETICAL  ORDER) 

This  Cable  identifies  system  parameters  and  briefly  describes 
their  utilization.  Nominal  values  are  given  to  assist  in 
understanding  the  algorithms.  The  performing  organization  is 
responsible  for  maintaining  a  consistent  set  of  units  within 
the  particular  system  being  implemented.  Variations  of  these 
parameters  will  be  made  in  the  appropriate  test  plans. 

*  These  thresholds  are  to  be  applied  directly  to  the  altitude  replies  of  the  aircraft 
when  the  replies  are  expressed  in  feet.  Neither  the  thresholds  nor  the  replies  from 
the  aircraft  are  to  be  adjusted  for  local  barometric  pressure. 

**  This  parameter  can  be  changed  via  an  external  device  in  real-time.  This  threshold  is 
to  be  applied  directly  to  the  altitude  replies  of  the  aircraft  when  the  replies  are 
expressed  in  feet. 


SYMBOL 

UTILIZATION 

NOMINAL  VALUE 

ABETA 

Smoothing  constant  used  in  azimuth  rate  estimation. 

.5 

ACCELC 

Upward  acceleration  modeled  in  response  to  a  vertical 
resolution  advisory. 

4  ft/s2 

ACCELD 

Downward  acceleration  modeled  in  response  to  a  vertical 
resolution  advisory. 

8  ft/s2 

ACONTH 

Vertical  range  used  in  calculation  of  TCONV.  See  PREPAR. 

See  Table 

7-11 

ADET 

Sets  miss  distance  threshold  (DSQ)  for  modified  tau  test. 

92.5  sec2 

AF 

Immediate  altitude  threshold  for  resolution  advisory 

See  SCMDF. 

See  Table 
and  Table 

7-11 

10-12 

AFCON 

Immediate  altitude  threshold  for  controller  alert. 

See  SCAFLG. 

See  Table 

7-11 

AFDET 

Immediate  altitude  threshold  for  Detect  Task  prefiltering. 

See  Table 

7-11 

AFIFR 

Immediate  altitude  threshold  for  controlled  aircraft 
threat  advisory.  See  SFPIF. 

See  Table 

7-11 

AFPWI 

Immediate  altitude  threshold  for  uncontrolled 
aircraft  threat  advisory.  See  SFPWF. 

See  Table 

7-11 

AHI 

Altitude  threshold  for  search  of  X-list  with  aircraft 
from  EX -list  in  coarse  screening. 

12,000  ft* 

TABLE  A-l 


SYSTEM  PARAMETERS 
(Cont inued) 


AIFR  Immediate  altitude  threshold  for  a  controlled  aircraft  See  Table  7-11 

resolution  advisory  set.  See  SIFRF. 

ALO  Altitude  boundary  for  EX-list  and  X-list  in  coarse  10,000  ft* 

screening. 

ALPC  Lower  limit  of  positive  controlled  airspace  used  to  18,000  ft* 

select  positive  resolution  advisory  altitude  threshold. 

ALTDP  Projection  altitude  used  in  resolution  advisory  vertical  See  Table  7-11 

divergence  logic.  See  SCMDF  and  SIFRF. 

ALUH  Lower  limit  of  ultra  high  altitude  airspace  used  to  29,000  ft* 

select  positive  resolution  advisory  altitude  threshold. 

ASEP  Positive  resolution  advisory  immediate  altitude  threshold  _ 


(ASEPH,  ASEPIL,  ASEPL,  ASEPU). 

ASEPH  High  altitude  positive  resolution  advisory  threshold.  670  ft 

ASEPIL  Low  altitude  positive  resolution  advisory  threshold  for  375  ft 

controlled/uncontrolled  and  controlled/controlled. 

ASEPL  Low  altitude  positive  resolution  advisory  threshold  for  470  ft 

uncontrolled  pair. 

ASEPU  Ultra  high  altitude  positive  resolution  advisory  770  ft 

threshold. 

ASEPV  Altitude  threshold  for  giving  VP0S  to  slow  aircraft.  350  ft 

ATERN  Altitude  threshold  below  which  a  descend  resolution 

advisory  is  not  used.  1000  ft** 

BANKA  Bank  angle  used  to  model  turn  in  Master  Resolution  Task.  20° 

BDET  Sets  miss  distance  threshold  (DSQ)  for  modified  tau  .107  nmi^ 

test. 

BDR0P  Number  of  scans  ATARS  must  wait  after  the  disappearance  2 

of  BCAS  resolution  advisories  for  a  conflict  before  the 
pair. record  can  be  dropped. 
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SYSTEM  PARAMETERS 
(Continued) 

1  ' 

)  ■ 
i 

j 

CAHTM 

Time  interval  between  requests  for  a  controller  alert 
advisory  to  delete  advisory  (“  2  scans). 

9.4  sec 

CAMR2 

Square  of  range  threshold  for  maneuvering  aircraft 
conflict  logic.  See  CAMAN. 

3.25  nmi 

CAMA 

Altitude  separation  threshold  for  maneuvering  aircraft 
conflict  alert  logic.  See  CAMAN. 

1000  ft 

CAMVSQ 

Square  of  aircraft  velocity  threshold  for  maneuvering 
aircraft  conflict  alert  logic.  See  CAMAN. 

325  kts2 

CAMCP2 

Square  of  cosine  of  the  angle  between  aircraft  velocities 
for  determing  parallelness.  See  CAMAN. 

.981 

CAMSB2 

Square  of  sine  of  the  angle  between  subject  aircraft 
velocity  and  target  aircraft  relative  position  vectors, 
which  determines  parallel  offset  or  parallel  in  trail 
condition.  See  CAMAN. 

.117 

C0AA2 

Cosine  squared  of  approach  angle  threshold  for 
determining  final  approach  status.  See  SATAZ. 

.9698 

C0SP2 

Square  of  the  cosine  of  the  angle  between  aircraft 
velocities  for  determining  parallelness.  See  SKTTF. 

.981 

DELAY 

Predicted  uplink  delay  plus  pilot's  delay  in  response 
to  resolution  advisories. 

■ 

11  sec 

DELTA 

Extra  heading  correction  in  tracking  when  turn  is  sensed 
on  two  consecutive  updates. 

15  degrees 

DOTTH 

Divergence  threshold  at  which  resolution  advisories  are 
inhibited. 

.00278  nmi2 
sec 

(10  nmi-kts) 

FESTAB 

Firmness  value  used  to  determine  if  track  is  qualified 
for  ATARS  processing. 

6 
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HMIN 

HUBRAD 

HZONE 

LRGTAU 

MCTA 

MDCON2 

MDFPI2 

MDFPW2 

MDHSQ 

MDTHSQ 

MRATE 

MTU 

MTTA 


SYSTEM  PARAMETERS 
(Continued) 


Miniumum  time  threshold  in  horizontal  direction  for  20  sec 

bypassing  2/3  sliding  window  maneuver  logic.  See 
SCMDF  and  SIFRF. 

Radius  of  hub  processing  area.  10  nmi 

Altitude  used  to  separate  high  from  low  geographical  18,000  ft* 

zone. 


Value  of  horizontal  tau  which  must  be  larger  than  any  value  999  sec 
which  can  be  computed  in  the  Detect  Task.  This  value  is 
assigned  to  horizontal  tau  in  the  Compute  Threat  Segment 
Data  Routine  when  aircraft  are  diverging. 

Number  of  scans  out  of  NCTA  scans  for  which  the  CAFLG  3 

must  be  set  in  order  to  generate  a  Controller  Alert 
Message. 

Square  of  miss  distance  threshold  for  controller  alert.  See  Table  7-11 

See  S CAFLG. 


Square  of  miss  distance  threshold  for  issuing  a  threat 
advisory  to  controlled  aircraft.  See  SFPIF. 

Square  of  miss  distance  threshold  for  issuing  a  threat 
advisory  to  uncontrolled  aircraft.  See  SFPWF. 

Square  of  horizontal  miss  distance  at  which  resolution 
strategy  changes. 

Square  of  horizontal  miss  distance  threshold  for  giving 
positive  resolution  advisories. 

Minimum  vertical  rate  required  to  choose  Vertical 
Speed  Limit  (VSL)  resolution  advisories. 

Lower  limit  on  maneuver  time  in  PSEP  calculation. 


See  Table  7-1 1 

See  Table  7-11 

0.083  nmi2 
(1750  ft)2 

.25  nmi2 
400  ft/min 

30  sec 


Altitude  separation  threshold  for  maneuvering  target  1000  ft 

threat  logic.  See  SMTTF. 


MTTR2 


Square  of  range  threshold  for  maneuvering  target  threat 
logic.  See  SMTTF. 


3.25  nmi2 
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SYSTEM  PARAMETERS 
(Continued) 

MTTRM2 

Check  against  range  to  prevent  divide  by  zero.  See 

SMTTF. 

.00244  nmi^ 

MTTSB2 

Threshold  for  square  of  sine  of  angle  between  subject 
aircraft  velocity  and  target  aircraft  relative  position 
vectors,  which  determines  parallel  offset  or  parallel 
in  trail  status.  See  SMTTF. 

.117 

MTTVR2 

Square  of  relative  velocity  threshold  for  determining 
slow-closing  status.  See  SMTTF. 

1600  kts2 

MTTVSQ 

Square  of  aircraft  velocity  threshold  for  maneuvering 
target  threat  filtering.  See  SMTTF. 

325  kts2 

MTUL 

Upper  limit  on  maneuver  time  in  PSEP  calculation 

120  sec 

NCTA 

Window  for  generation  of  Controller  Alert  Message. 

5 

OBALT 

Altitude  limit  above  which  the  obstacle  detection  logic 
is  not  executed. 

3000  ft* 

OBXCK 

X  distance  value  for  obstacle  proximity  check 

2000  ft 

OBYCK 

Y  distance  value  for  obstacle  proximity  check 

2000  ft 

OBZCK 

Z  distance  value  for  obstacle  proximity  check 

500  ft 

OGHDIF 

Minimum  absolute  value  of  difference  between  (last 

own  ground  track  heading  plus  turn  rate  X  delta  time)  and 

(current  own  ground  track  heading)  to  generate  new 

Own  Message. 

12o 

PWIZ 

Altitude  difference  determining  whether  two  aircraft  are 
co-altitude. 

500  ft 

RCMD2 

Square  of  horizontal  immediate  range  for  resolution 
advisory  set.  See  SCMDF. 

See  Table  7-11 
and  Table  10-12 

RCONTH 

Horizontal  range  used  in  calculation  of  TCONH. 

See  PREPAR. 

See  Table  7-11 
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SYSTEM  PARAMETERS 
(Continued) 


RCON2 

Square  of  horizontal  immediate  range  for  controller 
alert.  See  SCAFLG. 

See  Table 

7-11 

RDET 

Immediate  range  threshold  for  Detect  Task  prefiltering 

See  Table 

7-11 

RDIST 

Range  from  radar  used  to  separate  area  types  3  and  4. 

90  nmi 

RDISTR 

Distance  from  the  radar  where  range-azimuth  data 
becomes  unreliable. 

90  nmi 

RFIFR2 

Square  of  horizontal  immediate  range  for  a  threat  advisory 
to  controlled  aircraft. 

See  Table 

7-11 

RFPWI2 

Square  of  horizontal  immediate  range  for  a  threat  advisory 
to  uncontrolled  aircraft.  See  SFPWF. 

See  Table 

7-11 

RIFR2 

Square  of  horizontal  immediate  range  for  resolution 
advisory  to  controlled  aircraft. 

See  Table 

7-11 

RMAX 

Maximum  distance  traveled  by  an  aircraf,t  over  the  longest 

appropriate  system  look-ahead  time  (RMAXI,  RMAXH,  RMAXV). 

RMAXH 

Maximum  distance  traveled  by  intruding  aircraft  in 

EX-list  coarse  screen  filter. 

20.0  nmi 

RMAXI 

Maximum  distance  traveled  by  intruding  aircraft  in 
coarse  screening  filter  for  a  controlled  subject 
aircraft. 

8.0  nmi 

RMAXV 

Maximum  distance  traveled  by  intruding  aircraft  in 
coarse  screening  filter  for  an  uncontrolled  subject 
aircraft. 

5.0  nmi 

RPMIH 

The  square  of  the  minimum  range  at  which  a  proximity 
advisory  is  given. 

4.0  nmi^ 

RPWI 

Maximum  effective  proximity  advisory  range. 

4.0  nmi 

SCANTM 

Nominal  time  interval  for  one  radar  scan. 

4.7  sec 

SEP1 

3-D  slant  range  used  in  resolution  to  evaluate  resolution 
advisories. 

.0271  nmi2 
(1000  ft)2 
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SYSTEM  PARAMETERS 
(Continued) 


SEP2 

3-D  slant  range  used  in  resolution  to  evaluate  resolution 
advisories. 

.0531  nmi^ 

(1400  ft)2 

SPL02 

Square  of  maximum  assumed  speed  for  aircraft  below 

10,000  ft.  MSL. 

.004444 

nmi^/sec^ 

(240  kts)2 

TAF 

Current  altitude  threshold  used  in  resolution. 

1000  ft 

TCMDH 

Horizontal  tau  threshold  for  resolution  advisory  set. 

See  SCMDF. 

See  Table 
and  Table 

7-11 

10-12 

TCMDV 

Vertical  tau  threshold  for  resolution  advisory  set. 

See  SCMDF. 

See  Table 
and  Table 

7-11 

10-12 

TCONH 

Horizontal  tau  threshold  for  controller  alert. 

See  SCAFLG. 

See  Table 

7-11 

TCONV 

Vertical  tau  threshold  for  controller  alert. 

See  SCAFLG. 

See  Table 

7-11 

TDOS 

Scan  time  correction  threshold. 

.1  sec 

TDP 

Projection  time  in  resolution  advisory  vertical  divergence 
logic.  See  SCMDF  and  SIFRF. 

See  Table 

7-11 

TDROP 

Time  interval  without  a  horizontal  reply  to  drop  a  track. 

19  sec 

TFIFRH 

Horizontal  tau  threshold  for  a  threat  advisory  to  a 
controlled  aircraft.  See  SFPIF. 

See  Table 

7-11 

TFIFRV 

Vertical  tau  threshold  for  a  threat  advisory  to  a 
controlled  aircraft.  See  SFPIF. 

See  Table 

7-11 

TFPWIH 

Horizontal  tau  threshold  for  a  threat  advisory  to  an 
uncontrolled  aircraft.  See  SFPWF. 

See  Table 

7-11 

TFPWIV 

Vertical  tau  threshold  for  a  threat  advisory  to  an 
uncontrolled  aircraft.  See  SFPWF. 

See  Table 

7-11 

THMS 

Rho,  Theta  measurement  time  interval  required  to  zero 
horizontal  maneuver  status. 

5  sec 
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THVDIF 

THVPER 

TIFRH 

TIFRV 

TIMINT 

TLA 

TLD 

TLI 

TLPSQ 

TLV 

TMZMAX 

TRALT 

TRECOM 

TRHTM 

TRKS1 

TRKS2 


SYSTEM  PARAMETERS 
(Continued) 


Minimum  absolute  value  of  difference  between  last 
delivered  threat  velocity  and  current  threat  velocity 
required  in  test  for  start  threat  advisory. 

Minimum  percentage  difference  between  last  delivered 
threat  velocity  and  current  threat  velocity  required  in 
test  for  start  threat  advisory. 

Horizontal  tau  threshold  for  a  controlled  aircraft 
resolution  advisory  set.  See  S1FRF. 

Vertical  tau  threshold  for  a  controlled  aircraft 
resolution  advisory  set.  See  SIFRF. 

Time  value  equal  to  one-half  of  a  radar  scan. 

Largest  appropriate  look-ahead  time  (TLI,  TLV). 

Total  look-ahead  time  used  in  Domino  Coarse  Screen 
Routine. 

Longest  look-ahead  time  for  a  controlled  aircraft  in  the 
coarse  screening  filter. 

Square  of  proximity  advisory  time  parameter. 

Longest  look-ahead  time  for  an  uncontrolled  aircraft  in 
the  coarse  screening  filter. 

Maximum  time  since  last  altitude  report  for  track 
to  qualify  for  ATARS  processing. 

Altitude  above  which  terrain  avoidance  logic  is  not 
executed. 

Time  delay  before  test  of  recomputation  of  horizontal 
resolution  advisories. 

Horizontal  projection  time  for  terrain  bin  checks. 

Strong  turn  sensing  parameter  (range  factor). 

Strong  turn  sensing  parameter  (azimuth  factor). 


20  kts 


.10 


See  Table  7-11 

See  Table  7-11 

2.35  sec 


120  sec 

900  sec^ 
75  sec 

15  sec 

5000  ft* 

27  sec 

60  sec 

.9 

.9 
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TRKW1 

TRKW2 

TSCMD 

TTH 

TTM 

TURNA 

TV1 
TV  2 
TVDP 

TWARN 

TXTH1 

TXTH2 

V500 

V1000 

V2000 

VPACTR 

VFAST 


SYSTEM  PARAMETERS 
(Continued) 


Weak  turn  sensing  parameter  (range  factor). 

Weak  turn  sensing  parameter  (azimuth  factor). 

Minimum  duration  of  positive  resolution  advisories. 

Extra  heading  correction  in  tracking  when  turn  is 
sensed  in  two  consecutive  updates. 

Used  to  determine  resolution  advisory  time 
threshold  delta  in  resolution. 

Angle  the  aircraft  is  expected  to  turn  through  in 
response  to  horizontal  resolution  advisories. 

Look-ahead  time  threshold  for  altitude  crossover. 

Look-ahead  time  threshold  to  allow  level  off. 

Tau  threshold  for  resolution  advisory  vertical 
divergence  logic.  See  SCMDF  and  SIFRF. 

Warning  time  used  in  calculation  of  TCONV  and  TCONH. 

The  lower  limit  for  the  track  crossing  angle  at  which 
the  resolution  strategy  changes. 

The  upper  limit  for  the  track  crossing  angle  at  which 
the  resolution  strategy  changes. 

Threshold  for  500  ft/min  VSL  resolution  advisory. 

Threshold  for  1000  ft/min  VSL  resolution  advisory. 

Threshold  for  2000  ft/min  VSL  resolution  advisory. 

Vertical  factor  used  for  weighting  vertical  separation 
relative  to  horizontal. 

Speed  threshold  used  for  giving  vertical  resolution 
advisories. 


.5 

0 

7  sec 

40  degrees 

2 

180° 

8  sec 
16  sec 

See  Table  7-11 

See  Table  7-11 
600 

1200 

8.33  ft/sec 
16.67  ft/sec 

33.33  ft/sec 
5.0 

.0025  nmi^/eec* 
(180  kts)2 
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VMDTH 

VMIN 

VP1 

VPCS 

VRATC 

VRATIO 

VRATTH 

VRZCON 

VRZTH 

VS  LOW 

VTHSQ 

VWEGHT 
WAC1 
VAC  2 


SYSTEM  PARAMETERS 
(Continued) 


Square  of  relative  horizontal  velocity  threshold  for 
computing  miss  distance. 

Minimum  time  threshold  in  vertical  direction  for  by 
passing  2/3  sliding  window  to  maneuver  logic.  See 
SCMDF  and  SIFRF . 

Altitude  proximity  for  generation  of  a  proximity  advisory. 

Vertical  proximity  test  limit  used  in  coarse  screening 
filter. 

Squared  speed  ratio  for  giving  the  controlled  aircraft 
resolution  advisories  at  the  same  time  as  uncontrolled, 
when  the  controlled  aircraft  is  much  faster  than  the 
uncontrolled. 

Squared  speed  ratio  threshold  for  giving  double  resolution 
advisories  when  a  fast  unequipped  aircraft  is  conflicting 
with  a  slow  equipped  aircraft. 

Squared  speed  ratio  threshold  for  determining  look-ahead 
time  in  unequipped/equipped  encounters. 

Relative  speed  threshold  used  to  test  for  vertical 
slow  closing  or  divergence. 

Threshold  to  prevent  division  by  zero  in  computation  of 
vertical  TAU. 

Speed  threshold  used  for  giving  horizontal  resolution 
advisory. 

Square  of  speed  threshold  used  to  determine  if  aircraft 
is  fast  or  slow. 

Vertical  weight  for  computing  3-D  weighted  slant  range. 
Range  weighting  factor  for  ATCRBS  correlation. 

Range  rate  weighting  factor  for  ATCRBS  correlation. 


100  kts2 

20  sec 

2000  ft 
2000  ft 

2.25 

2.25 

2.25 

-300  fpm 

15  ft/min 

.00111  nmi2/8ec2 
(120  kts)2 

.00174  nmi2/aec2 
(150  kts)2 

5.0 

40  nmi”2 

1000  sec2/nai2 
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SYSTEM  PARAMETERS 
(Continued) 

WAC3 

Bearing  weighting  factor  for  ATCRBS  correlation. 

.001  deg-2 

WAC4 

Bearing  rate  weighting  factor  for  ATCRBS  correlation. 

.01  sec2/deg2 

WAC5 

Altitude  weighting  factor  for  ATCRBS  correlation. 

.000025  ft"2 

WAC6 

Altitude  weighting  factor  for  ATCRBS  correlation. 

.000025  sec2/ft2 

XBNER 

X  distance  value  used  to  determine  if  Y-line  cross  is 
near  an  adjacent  bin. 

1  nmi 

XCORR 

X  and  Y  correlation  limit  for  ATCRBS  correlation. 

3000  ft 

XSP 

Spacing  between  signposts  in  the  X-list. 

5  nmi 

YBNER 

Y  distance  value  used  to  determine  if  X-line  cross  is 
near  an  adjacent  bin. 

1  nmi 

ZAFCON 

Minimum  altitude  separation  between  aircraft  when  both 
are  in  zone  2.  See  CAFLG. 

275  ft. 

ZCORR 

Z  correlation  limit  for  ATCRBS  correlation. 

300  ft 

ZDDWNF 

Used  to  model  descent  rate  of  fast  aircraft  in  the 
separation  matrix. 

41.6  ft/sec 

ZDDWNS 

Used  to  model  descent  rate  of  slow  aircraft  in  the 
separation  matrix. 

25.0  ft/sec 

ZDTH 

Vertical  rate  threshold  to  determine  when  an  unequipped 
aircraft  has  a  threatening  rate  and  to  determine  when 
vertical  negative  resolution  advisories  are  disruptive  to 
an  equipped  aircraft. 

6  ft/sec 

ZDUPF 

Used  to  model  climb  rate  of  fast  aircraft  in  the 
separation  matrix. 

25.0  ft/sec 

ZDUPS 

Used  to  model  climb  rate  of  slow  aircraft  in  the 
separation  matrix. 

8.3  ft/sec 

ZFAST 

Z  velocity  threshold  for  non-subject  aircraft  in 
coarse  screening. 

16.67  ft/aac 
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SYSTEM  PARAMETERS 
(Concluded) 


ZHMNX, 

ZHMXX, 

ZHMNY, 

AHMXY, 

Minimum  and  maximum  X  and 
rectangle  to  encompus  all 
an  airfield. 

Y  respectively  to  form  a 
area  typea  1  and  2  for 

Site  Adaptable 

ZJMNX, 

ZJMXX, 

ZJMNY, 

ZJMXY, 

Minimum  and  maximum  X  and 
rectangle  to  encompua  all 
an  airfield. 

Y  respectively  to  form  a 
zone  types  1  and  2  for 

Site  Adaptable 

ZNOM 

Altitude  uaed  in  alant  range  correction  when  no  altitude 
meaaurement  ia  available. 

5000  ft 

ZRCON2 

Square  of  minimum  range  allowed  between  aircraft  when 
both  are  in  zone  2.  See  CAFLG. 

.25  nmi^ 

ZZONZ2 

One  half  of  type  2  final  approach  zone  vertical  extent. 

200  ft 
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FLOW  CHART  ABBREVIATIONS 


Abbreviation 


Word 


ABS 

AC,  A/C 

ADJ 

ADV 

ALT 

ANT 

AZIM 

CA 

CALC 

CC 

CK(S) 

COMP 

CONF 

CONT,  CONTR 

COORD 

CORK 

CTE 

CT 

CU 

DET 

DIST 

DZB 

EQ,  EQUIP 
.EQ. 

EST 

EVAL 

EXT 

.GE. 

GRND 

.GT. 

HOR,  HORIZ 

ID 

IND 

INIT 

INT 

•  US  • 

.LT. 

MAX 

MC 

MIN 


absolute  value 

aircraft 

adjacent 

advisory 

altitude 

antenna 

azimuth 

controller  alert 
calculate 

controlled/controlled 

check(s) 

compute 

conflict 

controlled 

coordinates 

corresponding 

conflict  table  entry 

conflict  table 

controlled/uncontrolled 

determine 

distance 

diffraction  zone  bit 

equipped 

equal  to 

estimate 

evaluation 

externa'. 

greater  than  or  equal  to 
ground 

greater  than 
horizontal 
identification 
indicate 
initialization 
internal,  integer 
less  than  or  equal  to 
less  than 
maximum  value 
most  critical 
minimum  value,  minute 
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FLOW  CHART  ABBREVIATIONS 
(Continued!) 


Abbreviation 


Word 


MSG(S) 

N/A 

.HE. 

NEG 

NO(S) 

NORM 

POS 

POT,  POTENT 
PR 

PRED,  PREDICT 

PROC 

PROX 

PT 

PTR,  PTS 

RAD 

REC(S) 

REF 

REQ,  REQD 
RES 

RES  ADV(S) 

RESTRICT 

ROUT 

RPT 

RQSTING 

SCR 

SECT 

SEQ 

SIGN 

SP 

SQRT 

SUBJ 

SUPPL 

SVC 

THRES 

THRO 

TRK 

UNC,  UNCO NT, 
UNCONTR 
UNEQ,  UNEQUIP 
UTM 


oesaage(a) 

not  applicable 
not  equal  to 
negative 
number(a) 
normal 

position,  positive,  position  data 

potential 

pair  record 

predicted,  prediction 

processing 

proximate,  proximity 
point 

pointer(s) 

radius 

record(s) 

reference 

required 

resolution 

resolution  advisory(s)  (this  abbr.  should 

not  be  confused  with  the  data  item  RESADV) 

restricted 

routine 

report 

requesting 

screen 

sector 

sequence 

sign  function 

signpost 

square  root 

subject 

supplemental 

service 

thresholds 

through 

track 

uncontrolled 

unequipped 

universal  transverse  mercator  coordinate 
system 
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FLOW  CHART  ABBREVIATIONS 
(Concluded) 


Abbreviation 

VAL 

VEL 

Z 


Word 

value 

velocity 

aircraft  altitude 
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